home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 3_7_03.tro < prev    next >
Text File  |  1991-12-12  |  94KB  |  3,776 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright ( c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v | 5i'
  22. .sp 2P
  23. .LP
  24. \fBRecommendation\ I.122\fR 
  25. .RT
  26. .sp 2P
  27. .sp 1P
  28. .ce 1000
  29. \fBFRAMEWORK\ FOR\ PROVIDING\ ADDITIONAL\ PACKET\ MODE\ BEARER\ SERVICES\fR 
  30. .EF '%    Fascicle\ III.7\ \(em\ Rec.\ I.122''
  31. .OF '''Fascicle\ III.7\ \(em\ Rec.\ I.122    %'
  32. .ce 0
  33. .sp 1P
  34. .ce 1000
  35. \fI(Melbourne, 1988)\fR 
  36. .sp 9p
  37. .RT
  38. .ce 0
  39. .sp 1P
  40. .LP
  41. \fB1\fR     \fBIntroduction\fR 
  42. .sp 1P
  43. .RT
  44. .PP
  45. Packet mode bearer services supported by an ISDN are given in
  46. Recommendation\ I.232. Recommendation\ I.462 (X.31) specifies the procedures 
  47. for two such bearer services, virtual call and permanent virtual circuit 
  48. bearer 
  49. services, for the support of X.25 packet mode terminals in ISDN.
  50. .PP
  51. This Recommendation establishes an architectural framework within
  52. which additional packet mode bearer services are described.
  53. .RT
  54. .sp 1P
  55. .LP
  56. 1.1
  57.     \fIScope\fR 
  58. .sp 9p
  59. .RT
  60. .PP
  61. The architectural framework and service descriptions given in this Recommendation 
  62. provide the basis for further work to be done by CCITT during 
  63. the 1989\(hy1992 Study Period. This method of work involves first the description 
  64. of services and then the development of protocols to support them. 
  65. .PP
  66. During the course of this work the first ISDN principle given in
  67. Recommendation\ I.120 should be followed. That is, a wide range of applications 
  68. should be supported by the same network using a limited set of connection 
  69. types and multipurpose user\(hynetwork interface arrangements. From considerations 
  70. in 
  71. this Recommendation it is also desirable to limit the number of bearer
  72. services. It is recognized, however, that at this time it is premature to
  73. exclude any potential bearer services. The criteria on the basis of which 
  74. the number of these bearer services could be reduced requires further study. 
  75. .PP
  76. The Recommendation also provides a 
  77. general description on
  78. interworking
  79. requirements between I.122 based services and I.462 (X.31)
  80. based services or PSPDNs.
  81. .RT
  82. .sp 1P
  83. .LP
  84. 1.2
  85.     \fIObjectives\fR 
  86. .sp 9p
  87. .RT
  88. .PP
  89. The principle of separation of the user and control planes for all telecommunication 
  90. services has been established as a fundamental concept of the ISDN protocol 
  91. reference model (Rec.\ I.320). This principle has been 
  92. applied, however, only to circuit mode services. Packet mode services in 
  93. ISDN are based on Recommendation\ I.462 (X.31). Recommendation\ I.462 (X.31) 
  94. is a 
  95. pragmatic approach that minimizes deployment and interworking difficulties,
  96. while at the same time providing access to packet services through an
  97. integrated physical interface.
  98. .PP
  99. The evolution of packet mode services in ISDN has been investigated, and 
  100. an architectural framework for providing additional packet mode services 
  101. has been established in this Recommendation. In undertaking this investigation 
  102. the main objective was to establish a framework based on the ISDN protocol 
  103. reference models described in Recommendation\ I.320. More specifically, this
  104. framework was aimed at achieving:
  105. .RT
  106. .LP
  107.     a)
  108.      full integration of C\(hyplane (control plane) procedures for all services, 
  109. i.e.\ one set of protocols for call control; supplementary 
  110. services and operational, administrative and maintenance messages (OAM) 
  111. across all telecommunication services; 
  112. .LP
  113.     b)
  114.     the decoupling of user information transfer requirements
  115. from C\(hyplane transfer requirements. This allows the possibility of defining
  116. telecommunication services whose U\(hyplane (user plane) characteristics are
  117. tailor\(hymade only to the transfer needs of user information and not to 
  118. those of C\(hyplane information. 
  119. .PP
  120. The bearer services supported within this architectural framework are in 
  121. the virtual call and permanent virtual circuit bearer service category. 
  122. All bearer services defined within this framework if and when included 
  123. in 
  124. Rec.\ I.232 will have recommended overall provision\ A (Additional).
  125. .bp
  126. .sp 1P
  127. .LP
  128. 1.3
  129.     \fIDefinitions of terms\fR 
  130. .sp 9p
  131. .RT
  132. .PP
  133. In the context of this Recommendation, the following definitions
  134. apply:
  135. .PP
  136. \fINote\fR \ \(em\ This list is not complete. For example, some of these
  137. definitions apply to terms relevant to only some of the bearer services
  138. discussed in this Recommendation.
  139. .RT
  140. .sp 1P
  141. .LP
  142. 1.3.1
  143.     \fBdelivered duplicate frames\fR 
  144. .sp 9p
  145. .RT
  146. .PP
  147. A frame D received by a particular destination user is defined to be a 
  148. duplicated frame if both of the following conditions are true: 
  149. .RT
  150. .LP
  151.     a)
  152.     D was not generated by the source user;
  153. .LP
  154.     b)
  155.     D is exactly the same as a frame that was previously
  156. delivered to that destination.
  157. .sp 1P
  158. .LP
  159. 1.3.2
  160.     \fBdelivered errored frames\fR 
  161. .sp 9p
  162. .RT
  163. .PP
  164. A delivered frame is defined to be an errored frame when the
  165. value of one or more bits in the frame is in error, or when some, but not 
  166. all, bits in the frame are lost bits or extra bits (i.e.\ bits that were 
  167. not present in the original signal). (See Rec.\ X.140). 
  168. .RT
  169. .sp 1P
  170. .LP
  171. 1.3.3
  172.     \fBdelivered out\(hyof\(hysequence frames\fR 
  173. .sp 9p
  174. .RT
  175. .PP
  176. \fI\fR Consider a sequence of frames \fIF\fR\d1\u, \fIF\fR\d2\u, \fIf\fR\d3\u, |  |  | , 
  177. \fIF\fR\d\fIn\fR\u. Assume that \fIF\fR\d1\uis transmitted first, \fIF\fR\d\fI2\fR\usecond, 
  178.  |  |  |  
  179. \fIF\fR\d\fIn\fR\ulast.
  180. .PP
  181. A delivered frame \fIF\fR\d\fIi\fR\uis defined to be out\(hyof\(hysequence 
  182. if it 
  183. arrives at the destination user after any of the frames\ \fIF\fR \d(\fIi\fR 
  184. \ +\ 1) 
  185. \u,   \fIF\fR \d(\fIi\fR \ +\ 2)
  186. \u,  |  |  | , \fIF\fR\d\fIn\fR\u.
  187. .RT
  188. .sp 1P
  189. .LP
  190. 1.3.4
  191.     \fBdynamic window control\fR 
  192. .sp 9p
  193. .RT
  194. .PP
  195. The term dynamic window control refers to a set of procedures
  196. based on which the transmitter's transmit window is modified, according to a
  197. user\(hyperceived congestion condition in the network.
  198. .RT
  199. .sp 1P
  200. .LP
  201. 1.3.5
  202.     \fBend\(hyto\(hyend communication\fR 
  203. .sp 9p
  204. .RT
  205. .PP
  206. End\(hyto\(hyend communication is a direct peer\(hyto\(hypeer communication 
  207. of TE to TE, or TE to a network interworking function (IWF) supporting, 
  208. for 
  209. example, PSPDN interworking.
  210. .RT
  211. .sp 1P
  212. .LP
  213. 1.3.6
  214.     \fBexplicit congestion message\fR 
  215. .sp 9p
  216. .RT
  217. .PP
  218. Explicit congestion message is a message generated by the network and sent 
  219. to a user terminal to indicate a congestion condition. 
  220. .RT
  221. .sp 1P
  222. .LP
  223. 1.3.7
  224.     \fBimplicit congestion control\fR 
  225. .sp 9p
  226. .RT
  227. .PP
  228. Implicit congestion control is a scheme under which user terminals first 
  229. detct a possible congestion condition by means other than explicit 
  230. congestion messages, and then take appropriate action to reduce their
  231. throughput.
  232. .RT
  233. .sp 1P
  234. .LP
  235. 1.3.8
  236.     \fBinformation integrity\fR 
  237. .sp 9p
  238. .RT
  239. .PP
  240. Information integrity is a network providing frame\(hyrelaying bearer service 
  241. defines that all frames carried by the network shall satisfy the FCS 
  242. check.
  243. .RT
  244. .sp 1P
  245. .LP
  246. 1.3.9
  247.     \fBlogically separate (C\(hyplane information)\fR 
  248. .sp 9p
  249. .RT
  250. .PP
  251. Logically separate means that C\(hyplane information is sent
  252. separately from U\(hyplane information in one of the following ways:
  253. .RT
  254. .LP
  255.     1)
  256.     on a physically separate interface;
  257. .LP
  258.     2)
  259.     on another channel (time slot) within the same interface;
  260. or
  261. .LP
  262.     3)
  263.     on a separate logical link within the same channel
  264. (e.g.,\ D\(hychannel).
  265. .bp
  266. .sp 1P
  267. .LP
  268. 1.3.10
  269.     \fBlost frames\fR 
  270. .sp 9p
  271. .RT
  272. .PP
  273. A transmitted frame is declared to be a lost frame when the frame is not 
  274. delivered to the intended destination user within a specified timeout 
  275. period, and the network is responsible. (See Rec.\ X.140).
  276. .RT
  277. .sp 1P
  278. .LP
  279. 1.3.11
  280.     \fBmisdelivered frames\fR 
  281. .sp 9p
  282. .RT
  283. .PP
  284. A misdelivered frame is a frame transferred from a source user to a destination 
  285. user other than the intended destination user. It is considered inconsequential 
  286. whether the information is correct or incorrect in content. 
  287. (See Rec.\ X.140).
  288. .RT
  289. .sp 1P
  290. .LP
  291. 1.3.12
  292.     \fBquality of service (QOS)\(hyparameter set\fR (See
  293. Rec.\ X.213)
  294. .sp 9p
  295. .RT
  296. .PP
  297. For each QOS\(hyparameter, a set of \*Qsubparameters\*U is defined from 
  298. among the following possibilities: 
  299. .RT
  300. .LP
  301.     a)
  302.     a \fItarget\fR  | value which is the QOS value desired by the
  303. calling user;
  304. .LP
  305.     b)
  306.     the \fIlower quality acceptable\fR  | value which is the lowest
  307. QOS value agreeable to the calling user. (When the lowest quality acceptable
  308. refers to throughput, the term \*Qminimum\*U may be used, while when it 
  309. refers to transit delay, the term \*Qmaximum\*U may be used.); 
  310. .LP
  311.     c)
  312.      an \fIavailable\fR  | value which is the QOS that the network is willing 
  313. to provide; 
  314. .LP
  315.     d)
  316.     a \fIselected\fR  | value which is the QOS value to which the
  317. called user agrees.
  318. .sp 1P
  319. .LP
  320. 1.3.13
  321.     \fBreal time call establishment\fR 
  322. .sp 9p
  323. .RT
  324. .PP
  325. The term real time call establishment refers to a set of
  326. procedures based on which the communication can be started in a relatively
  327. short time (i.e.\ in the order of a few seconds) after the request is made.
  328. (See definition for demand communication establishment in
  329. Rec.\ I.130).
  330. .RT
  331. .sp 1P
  332. .LP
  333. 1.3.14
  334.     \fBresidual error rate\fR 
  335. .sp 9p
  336. .RT
  337. .PP
  338. Residual error rate is defined for both the additional packet\(hymode bearer 
  339. services and the corresponding layer services. 
  340. .PP
  341. The layer services corresponding to the additional packet\(hymode bearer 
  342. services are characterized by the exchange of service data units (SDUs). 
  343. For frame relaying\ 1, SDUs are exchanged at the functional boundary between 
  344. the 
  345. core functions of Recommendation
  346. .FS
  347. I.441* is I.441 with appropriate
  348. extensions. The use of the extensions may depend on each bearer service 
  349. and is for further study. 
  350. .FE
  351. and the end\(hyto\(hyend protocol implemented above them. For frame relaying\ 
  352. 2 and frame switching, SDUs are exchanged at the functional 
  353. boundary between the complete I.441* and the end\(hyto\(hyend functions 
  354. implemented above I.441*. For the X.25\(hybased additional packet mode 
  355. service (APMS), SDUs are exchanged at the functional boundary of X.25 PLP\(hyDTP 
  356. (packet layer 
  357. protocol\(hydata transfer part) and the end\(hyto\(hyend functions implemented 
  358. above. 
  359. .PP
  360. The network participates in this exchange by means of protocol data units 
  361. (PDUs). In frame relaying\ 1 and 2, PDUs are frames as defined in the 
  362. core functions of I.441*. In frame switching, PDUs are frames as defined in
  363. I.441*, while in X.25\(hybased APMS, they are packets as defined in X.25 PLP.
  364. .PP
  365. The residual error rate for the corresponding layer service of APMS is 
  366. defined as: 
  367. \v'6p'
  368. .RT
  369. .sp 1P
  370. .ce 1000
  371. \fIR\fR = 1 \(em
  372. @ { otal~correct~SDUs~delivered } over { otal~offered~SDUs } @ 
  373. .ce 0
  374. .sp 1P
  375. .PP
  376. .sp 1
  377. The residual error rate for the APMS is defined as the
  378. ratio:
  379. \v'6p'
  380. .sp 1P
  381. .ce 1000
  382. \fIR\fR = 1 \(em
  383. @ { otal~correct~PDUs~delivered } over { otal~offered~PDUs } @ 
  384. .ce 0
  385. .sp 1P
  386. .LP
  387. .sp 1
  388. .bp
  389. .sp 1P
  390. .LP
  391. 1.3.15
  392.     \fBthroughput\fR 
  393. .sp 9p
  394. .RT
  395. .PP
  396. Throughput for a virtual connection section
  397. .FS
  398. Virtual connection section is defined in Rec.\ X.134.
  399. .FE
  400. in a network providing the frame
  401. relaying bearer service, is the number of data bits contained between the
  402. address field and the FCS field of the frames successfully transferred 
  403. in one direction across that section per unit time. Successful transfer 
  404. means that the FCS check for each frame is satisfied. 
  405. .RT
  406. .sp 1P
  407. .LP
  408. 1.3.16
  409.     \fBtransit delay\fR 
  410. .sp 9p
  411. .RT
  412. .PP
  413. Transit delay is defined only between pairs of section
  414. boundaries
  415. .FS
  416. The definition of section boundaries is given in
  417. Rec.\ X.134.
  418. .FE
  419. . Transit delay of a frame protocol data unit (FPDU)
  420. .FS
  421. The
  422. definition of FPDU is given above in residual error rate.
  423. .FE
  424. starts at the
  425. time\ \fIt\fR\d1\uat which the first bit of the FPDU crosses the first 
  426. boundary, and ends at the time\ \fIt\fR\d2\uat which the last bit of the 
  427. FPDU crosses the second boundary. 
  428. .PP
  429. Transit delay = \fIt\fR\d2\u\(em\fIt\fR\d1\u.
  430. .RT
  431. .sp 2P
  432. .LP
  433. \fB2\fR     \fBService aspects\fR 
  434. .sp 1P
  435. .RT
  436. .sp 1P
  437. .LP
  438. 2.1
  439.     \fIGeneral service characteristics\fR 
  440. .sp 9p
  441. .RT
  442. .PP
  443. This Recommendation describes a set of potential 
  444. packet mode
  445. bearer services
  446. that have the following characteristics in
  447. common:
  448. .RT
  449. .LP
  450.     1)
  451.     All C\(hyplane procedures, if needed, are performed in a
  452. logically separate manner using protocol procedures that are integrated 
  453. across all telecommunications services (i.e.\ I.451 with appropriate extensions). 
  454. .LP
  455.     2)
  456.     The U\(hyplane procedures share the same layer 1 functions
  457. based on Rec.\ I.430/I.431. Moreover, they share the same core
  458. procedres, defined in \(sc\ 3.1, that among other functions allow for statistical 
  459. multiplexing of user information flows immediately above the layer\ 1 
  460. functions.
  461. .PP
  462. The basic bearer service provided by the network is the order
  463. preserving bidirectional transfer (see \(sc\ 2.3.1) of service data units
  464. (i.e.\ frames or packets) from one S/T reference point to another. The data
  465. units are routed through the network on the basis of an attached label
  466. (e.g.\ the data link connection identifier (DLCI) value of the frame). This
  467. .PP
  468. label is a logical identifier with local significance. In the virtual call
  469. case, the value of the logical identifier and the other associated parameters 
  470. are negotiated during the call set\(hyup by means of C\(hyplane procedures. 
  471. Depending on the bearer service and parameters, the network may accept 
  472. or reject the user requested service. In the permanent virtual circuit 
  473. case, the logical 
  474. identifier and the other associated parameters are defined by means of
  475. administrative procedures. The network treatment of the data units,
  476. (e.g.\ unacknowledged transfer, acknowledged transfer, error recovery) in
  477. addition to simple transfer, depends on the specific bearer service requested.
  478. .PP
  479. The user network interface structure at the S/T reference point allows 
  480. for the establishment of multiple virtual calls and/or permanent virtual 
  481. circuits to many destinations.
  482. .RT
  483. .sp 1P
  484. .LP
  485. 2.2
  486.     \fIQuality of Service parameters\fR 
  487. .sp 9p
  488. .RT
  489. .PP
  490. Each potential bearer service described in this Recommendation
  491. provides service quality that is characterized by the values of the following 
  492. parameters: 
  493. .RT
  494. .LP
  495.     1)
  496.     throughput;
  497. .LP
  498.     2)
  499.     transit delay;
  500. .LP
  501.     3)
  502.     information integrity;
  503. .LP
  504.     4)
  505.     residual error rate;
  506. .LP
  507.     5)
  508.     delivered errored frames;
  509. .LP
  510.     6)
  511.     delivered duplicated frames;
  512. .LP
  513.     7)
  514.     delivered out\(hyof\(hysequence frames;
  515. .bp
  516. .LP
  517.     8)
  518.     lost frames;
  519. .LP
  520.     9)
  521.     misdelivered frames;
  522. .LP
  523.     10)
  524.     others for further study.
  525. .PP
  526. \fINote\fR \ \(em\ The applicability and values of these parameters for
  527. different bearer services are for further study.
  528. .sp 1P
  529. .LP
  530. 2.3
  531.     \fIIndividual\fR \fIbearer service descriptions\fR 
  532. .sp 9p
  533. .RT
  534. .PP
  535. This section contains descriptions of four specific potential
  536. bearer services proposed for standardization:
  537. .RT
  538. .LP
  539.     a)
  540.     frame relaying 1,
  541. .LP
  542.     b)
  543.     frame relaying 2,
  544. .LP
  545.     c)
  546.     frame switching, and
  547. .LP
  548.     d)
  549.     X.25\(hybased additional packet mode.
  550. .sp 1P
  551. .LP
  552. 2.3.1
  553.     \fIFrame relaying 1 service description\fR 
  554. .sp 9p
  555. .RT
  556. .PP
  557. Frame relaying 1
  558. shares with the other services the general service characteristics and 
  559. quality of service parameters described in \(sc\(sc\ 2.1 and 2.2, respectively. 
  560. .PP
  561. The 
  562. frame relaying 1 data units
  563. are frames as defined in
  564. Rec.\ I.441. The basic bearer service provided is the unacknowledged
  565. transfer of frames from S/T to S/T reference point. More specifically, 
  566. in the U\(hyplane: 
  567. .RT
  568. .LP
  569.     1)
  570.      it preserves their order as given at one S/T reference point if and when 
  571. they are delivered at the other end. 
  572. .LP
  573.     \fINote\fR \ \(em\ Since the network does not terminate the upper part of
  574. I.441, sequence numbers are not kept by the network. Networks should be
  575. implemented in a way that, in principle, frame order is preserved;
  576. .LP
  577.     2)
  578.      it detects transmission, format and operational errors (e.g. frames of 
  579. unknown DLCI); 
  580. .LP
  581.     3)
  582.      frames are transported transparently (in the network), only the address 
  583. and FCS field may be modified; 
  584. .LP
  585.     4)
  586.     it does not acknowledge frames (within the network).
  587. .PP
  588. All of the above functions are based on Rec.\ I.441.
  589. Appropriate extensions to the core functions of Rec.\ I.441 may be
  590. needed, e.g.\ for congestion control. In the C\(hyplane all signalling
  591. capabilities for call control, parameter negotiation,\ etc. are based on a
  592. common set of protocols (e.g.\ Rec.\ I.451 extended), as for all ISDN
  593. telecommunication services. In the case of permanent virtual circuits (PVC) 
  594. no real time call establishment is necessary and parameters are agreed 
  595. upon at subscription time. 
  596. .PP
  597. However, additional functions are needed:
  598. .RT
  599. .LP
  600.     \(em
  601.     to monitor throughput and to enforce it,
  602. .LP
  603.     \(em
  604.     to control congestion.
  605. .PP
  606. The mechanisms to achieve these functions are still under
  607. investigation.
  608. .PP
  609. Appropriate protocol capabilities should be available so that the
  610. network may discard erroneous frames if it elects to do so. Note that if
  611. networks elect to forward erroneous frames to the user, fraud and misdelivery 
  612. of frames may occur. 
  613. .PP
  614. From the service perspective, frame relaying 1 provides service
  615. quality characteristics with the following parameter values:
  616. .PP
  617. (Parameter values are for further study).
  618. .RT
  619. .sp 1P
  620. .LP
  621. 2.3.2
  622.     \fIFrame relaying 2 service description\fR 
  623. .sp 9p
  624. .RT
  625. .PP
  626. Frame relaying 2
  627. shares with the other services the general service characteristics and 
  628. Quality of Service parameters described in \(sc\(sc\ 2.1 and 2.2, respectively. 
  629. .bp
  630. .PP
  631. The frame relaying data units are frames as defined in
  632. Rec.\ I.441. The basic bearer service provided is an unacknowledged
  633. transfer of frames from S/T to S/T reference point. More specifically, 
  634. in the U\(hyplane: 
  635. .RT
  636. .LP
  637.     1)
  638.      it preserves their order as given at one S/T reference point if and when 
  639. they are delivered at the other end. 
  640. .LP
  641.     \fINote\fR \ \(em\ Since the network does not terminate th upper part of
  642. I.441, sequence numbers are not kept by the network. Networks should be
  643. implemented in a way that, in principle, frame order is preserved;
  644. .LP
  645.     2)
  646.      it detects transmission, format and operational errors (e.g. frames of 
  647. unknown DLCI); 
  648. .LP
  649.     3)
  650.     frames are transported transparently in the network, only
  651. the address and FCS field may be modified;
  652. .LP
  653.     4)
  654.     it does not acknowledge frames (within the network);
  655. .LP
  656.     5)
  657.      normally the only frames received by a user are those sent by the distant 
  658. user. (Currently, implicit congestion control is preferred in 
  659. which the network does not generate any congestion control messages toward 
  660. the user. The generation of explicit congestion control messages by the 
  661. network is for further study.) 
  662. .PP
  663. All of the above functions are based on Rec.\ I.441.
  664. Appropriate extensions to Rec.\ I.441 may be needed, e.g.\ in relation
  665. to congestion control.
  666. .PP
  667. In the C\(hyplane all signalling capabilities for call control, parameter 
  668. negotiation,\ etc. are based on a common set of protocols 
  669. (e.g.\ Rec.\ I.451 extended), as for all ISDN telecommunication
  670. services. In the case of permanent virtual circuits (PVC) no real time call
  671. establishment is necessary and any parameters are agreed upon at subscription 
  672. time. 
  673. .PP
  674. However, additional network functions are needed:
  675. .RT
  676. .LP
  677.     \(em
  678.     to monitor throughput and to enforce it,
  679. .LP
  680.     \(em
  681.     to control congestion.
  682. .PP
  683. The mechanisms to achieve these functions are still under
  684. investigation.
  685. .PP
  686. Appropriate protocol capabilities should be available so that the
  687. network may discard erroneous frames if it elects to do so. Note that if
  688. networks elect to forward erroneous frames to the user, fraud and misdelivery 
  689. of frames may occur. 
  690. .PP
  691. The difference between the two types of frame relaying is that in
  692. frame relaying\ 2 the end points always implement, above the core functions, 
  693. the upper part of Rec.\ I.441 extended. Consequently, in frame relaying\ 
  694. 2 
  695. the network may take advantage of the knowledge of the layer\ 2 parameters in
  696. order to facilitate network operations such as charging and resource
  697. allocation. In frame relaying\ 1 the functions implemented end\(hyto\(hyend 
  698. above the core functions are user selectable and may not be the upper part 
  699. of 
  700. Rec.\ I.441. Consequently, in frame relaying\ 1 the network in
  701. principle has no knowledge of the protocol used end\(hyto\(hyend.
  702. .PP
  703. From the service perspective, frame relaying 2 provides service
  704. quality characteristics with the following parameter values:
  705. .PP
  706. (Parameter values are for further study).
  707. .PP
  708. The terminal operates with an extended I.441 protocol. As a result
  709. the user perspective is the transparent transport of data end\(hyto\(hyend, 
  710. with a 
  711. quality influenced by the statistical multiplexing of data streams in the
  712. network. Acknowledgement of data is end\(hyto\(hyend as well as error detection 
  713. and recovery. 
  714. .RT
  715. .sp 1P
  716. .LP
  717. 2.3.3
  718.     \fIFrame switching service description\fR 
  719. .sp 9p
  720. .RT
  721. .PP
  722. Frame switching
  723. has general service characteristics and
  724. Quality of Service parameters as given in \(sc\(sc\ 2.1 and 2.2, respectively.
  725. .PP
  726. In addition, in the U\(hyplane, frame switching:
  727. .RT
  728. .LP
  729.     1)
  730.     provides for the acknowledged transport of frames;
  731. .LP
  732.     2)
  733.     detects and recovers from transmission, format, and
  734. operational error;
  735. .LP
  736.     3)
  737.     detects and recovers from lost or duplicated frames;
  738. .LP
  739.     4)
  740.     provides flow control.
  741. .PP
  742. All of the above functions are based on Recommendation\ I.441.
  743. Appropriate extensions to Recommendation\ I.441 may be needed.
  744. .bp
  745. .PP
  746. In the C\(hyplane all signalling capabilities for all call control,
  747. parameter negotiation,\ etc. are based on a common set of protocols
  748. (e.g.\ Rec.\ I.451 extended), as for all ISDN telecommunication
  749. services. In the case of permanent virtual circuits no real time call
  750. establishment is necessary and any parameters are agreed upon at subscription 
  751. time. 
  752. .PP
  753. From the service perspective, frame switching provides service quality 
  754. characteristics with the following parameter values: 
  755. .PP
  756. (Parameter values are for further study).
  757. .RT
  758. .sp 1P
  759. .LP
  760. 2.3.4
  761.     \fIX.25\(hybased\fR \fIadditional packet mode service description\fR 
  762. .sp 9p
  763. .RT
  764. .PP
  765. X.25\(hybased additional packet mode has general service
  766. characteristics and Quality of Service parameters similar to the packet mode
  767. services described in X.31.
  768. .PP
  769. The U\(hyplane capabilities are the same as in X.25 PLP Data Transfer
  770. Part (DTP)
  771. .PP
  772. In the C\(hyplane all signalling capabilities for call control, parameter 
  773. negotiation,\ etc. are based on a common set of protocols 
  774. (e.g.\ Rec.\ I.451 extended), as for all ISDN telecommunication
  775. services. In the case of permanent virtual circuits (PVC) no real time call
  776. establishment is necessary and any parameters are agreed upon at subscription 
  777. time. 
  778. .RT
  779. .sp 2P
  780. .LP
  781. \fB3\fR     \fBUser\(hynetwork interface protocol reference model\fR 
  782. .sp 1P
  783. .RT
  784. .PP
  785. Figure 1/I.122 is a direct application of the ISDN protocol
  786. reference model to the packet mode communications discussed in this
  787. Recommendation. It shows the user\(hynetwork interface protocol architecture. 
  788. Only those functions on the network side that are visible on the user side 
  789. of the 
  790. S/T reference point are shown.
  791. .PP
  792. On the user side, Recommendations I.430 or I.431 provide the layer 1 protocol 
  793. for the U\(hy (user) C\(hy (control) planes. The C\(hyplane uses the D\(hychannel 
  794. with Recommendations\ I.441 extended and I.451 extended as the layer\ 2 
  795. and 3 
  796. protocols, respectively. In the case of permanent virtual circuits (PVC) no
  797. real time call establishment is necessary and any parameters are agreed 
  798. upon at subscription time. The U\(hyplane may use any channel (D, B, H\d0\uand 
  799. H\d1\u) on which the user implements at least the lower part (the core 
  800. functions) of 
  801. Recommendation\ I.441.
  802. .RT
  803. .LP
  804. .rs
  805. .sp 23P
  806. .ad r
  807. \fBFigure 1/I.122, p.\fR 
  808. .sp 1P
  809. .RT
  810. .ad b
  811. .RT
  812. .LP
  813. .bp
  814. .ce
  815. \fBH.T. [T1.122]\fR 
  816. .ce
  817. TABLE\ 1/I.122
  818. .ce
  819. \fBU\(hyplane functions applicable to each bearer service\fR 
  820. .ps 9
  821. .vs 11
  822. .nr VS 11
  823. .nr PS 9
  824. .TS
  825. center box;
  826. cw(96p) | cw(66p) | cw(66p) .
  827. Bearer service    User terminal  (Note 1)    Network
  828. _
  829. .T&
  830. lw(96p) | lw(66p) | lw(66p) .
  831. Frame relaying 1    I.441* Core  (Note 2)    I.441* Core
  832. _
  833. .T&
  834. lw(96p) | lw(66p) | lw(66p) .
  835. Frame relaying 2    I.441*    I.441* Core
  836. _
  837. .T&
  838. lw(96p) | lw(66p) | lw(66p) .
  839. Frame switching    I.441*    I.441*
  840. _
  841. .T&
  842. lw(96p) | lw(66p) | lw(66p) .
  843.  {
  844. X.25\(hybased additional packet mode
  845.  }    I.441* X.25 DTP    I.441* X.25 DTP
  846. .TE
  847. .LP
  848. \fINote\ 1\fR
  849. \ \(em\ Additional user selectable functions may be
  850. implemented.
  851. .LP
  852. \fINote\ 2\fR
  853. \ \(em\ I.441* is I.441 with appropriate extensions. The use of the
  854. extensions may depend on each bearer service and is for
  855. further study.
  856. .nr PS 9
  857. .RT
  858. .ad r
  859. \fBTable 1/I.122 [T1.122], p.\fR 
  860. .sp 1P
  861. .RT
  862. .ad b
  863. .RT
  864. .sp 1P
  865. .LP
  866. 3.1
  867.     \fICore functions of Rec. I.441\fR 
  868. .sp 9p
  869. .RT
  870. .PP
  871. The core functions are:
  872. .RT
  873. .LP
  874.     \(em
  875.     frame delimiting, alignment, and transparency,
  876. .LP
  877.     \(em
  878.     frame multiplexing/demultiplexing using the address field,
  879. .LP
  880.     \(em
  881.     inspection of the frame to ensure that it consists of an
  882. integer number of octets prior to zero bit insertion or following zero bit
  883. extraction,
  884. .LP
  885.     \(em
  886.      inspection of the frame to ensure that it is neither too long nor too 
  887. short (see Note), 
  888. .LP
  889.     \(em
  890.     detection of transmission errors.
  891. .PP
  892. \fINote\fR \ \(em\ The maximum and minimum frame lengths that apply to 
  893. the Additional packet mode bearer services are for further study. 
  894. .sp 1P
  895. .LP
  896. 3.2
  897.     \fIOther\fR \fIuser terminal functions\fR 
  898. .sp 9p
  899. .RT
  900. .PP
  901. If not already prescribed by the selected packet mode bearer
  902. service, the user may also implement functions such as, for example, recovery 
  903. from detected transmission, format, and operational errors above the core 
  904. functions using the full procedures of Recommendation\ I.441. Additional
  905. functions such as flow control may also be implemented. For example, X.25 
  906. data transfer functions may also be implemented above the preceding stack. 
  907. .RT
  908. .sp 1P
  909. .LP
  910. 3.3
  911.     \fINetwork functions\fR 
  912. .sp 9p
  913. .RT
  914. .PP
  915. On the network side, Recommendations I.430 or I.431 provide the
  916. layer 1 protocol for both C\(hy and U\(hyplanes. The C\(hyplane is handled 
  917. just as on 
  918. the user side, i.e.\ the network fully terminates the protocols of
  919. Recommendations\ I.441 and I.451. In the U\(hyplane, at least the core 
  920. functions of Recommendation\ I.441 protocol are terminated. The network 
  921. may terminate 
  922. additional protocol functions only as requested by the user and negotiated 
  923. and agreed to by the user and the network. The U\(hyplane protocols to 
  924. be terminated by the network are determined by the specific bearer service 
  925. requested by the user, and negotiated and agreed to by the user and network. 
  926. .PP
  927. Interactions between the U\(hy and C\(hyplanes of the terminal, and between 
  928. the U\(hy and C\(hyplanes of the network are independent. As a result, 
  929. coordination between the U\(hy and C\(hyplanes at the users equipment is 
  930. not the responsibility of the network. 
  931. .bp
  932. .PP
  933. During the three phases of a call (call establishment, data transfer, and 
  934. call clearing), C\(hy and U\(hyplane synchronization is achieved in a similar 
  935. way as for all ISDN telecommunications services. That is, after the C\(hyplane 
  936. has 
  937. established the connection, the U\(hyplane may commence data transfer with or
  938. .PP
  939. without an initialization procedure in the U\(hyplane. In the case of permanent
  940. virtual circuit the establishment and call clearing is accomplished by
  941. administrative procedures.
  942. .RT
  943. .sp 1P
  944. .LP
  945. 3.4
  946.     \fIFurther service requirements at the user\(hynetwork interface\fR 
  947. .sp 9p
  948. .RT
  949. .PP
  950. Procedures at the user\(hynetwork interface should be also applicable when 
  951. two users are connected via a circuit mode bearer service (permanent or 
  952. demand). Mechanisms that can be used to achieve this objective include, for
  953. example, the symmetrization of the procedure involved, or the use of additional 
  954. procedures for the determination of the asymmetric relationships. The selection 
  955. of such a mechanism is for further study. 
  956. .RT
  957. .sp 1P
  958. .LP
  959. 3.5
  960.     \fIPotential bearer services\fR 
  961. .sp 9p
  962. .RT
  963. .PP
  964. Four potential bearer services are identified as part of this
  965. architectural framework. The first potential bearer service, frame relaying\ 
  966. 1, is provided when no functions above the core functions are terminated 
  967. by the 
  968. network: if needed, such functions are terminated only end\(hyto\(hyend.
  969. .PP
  970. The second potential bearer service, frame relaying 2, is provided
  971. when no functions above the core functions are terminated by the network; 
  972. I.441 upper functions are terminated only at the end points. 
  973. .PP
  974. The third potential bearer service, frame switching, is provided when the 
  975. full Recommendation\ I.441 protocol is terminated by the network. 
  976. .PP
  977. The fourth potential bearer service, X.25\(hybased additional packet
  978. mode, is provided when the full Recommendation\ I.441 protocol and the data
  979. transfer part (DTP) of Recommendation\ X.25 PLP (packet layer protocol) are
  980. terminated by the network.
  981. .PP
  982. Further information on the service characteristics of these four
  983. potential bearer services is given in Annex\ A.
  984. .RT
  985. .sp 2P
  986. .LP
  987. \fB4\fR     \fBInterworking requirements\fR 
  988. .sp 1P
  989. .RT
  990. .sp 1P
  991. .LP
  992. 4.1
  993.     \fIInterworking between packet mode services\fR 
  994. .sp 9p
  995. .RT
  996. .PP
  997. To interconnect different packet mode bearer services, it is
  998. necessary to provide interworking between an ISDN offering any of the bearer
  999. services described in this Recommendation, and:
  1000. .RT
  1001. .LP
  1002.     1)
  1003.     an ISDN offering any of these additional packet mode bearer  services,
  1004. .LP
  1005.     2)
  1006.     an X.25\(hybased service offered either by an ISDN or a
  1007. PSPDN.
  1008. .PP
  1009. For interworking configuration 1), procedures for both the C\(hyplane and
  1010. the U\(hyplane at an internetwork reference point which includes international
  1011. gateway reference points, have to be standardized. In addition it would be
  1012. desirable that these procedures be developed in such a way that they also 
  1013. could be used at an inter\(hyexchange reference point within an ISDN offering 
  1014. any of the bearer services described in this Recommendation. Examples of 
  1015. such procedures may include: routing, address translation, security and 
  1016. accounting tasks. 
  1017. .PP
  1018. For interworking configuration 2), interworking based on either call control 
  1019. mapping or port access is possible. A high level description of 
  1020. interworking arrangements is contained in Annex\ B.
  1021. .RT
  1022. .sp 1P
  1023. .LP
  1024. 4.2
  1025.     \fISupport of existing terminals\fR 
  1026. .sp 9p
  1027. .RT
  1028. .PP
  1029. Additionally, terminal adapter functions should be provided that
  1030. allow existing terminals (e.g.\ asynchronous, start/stop DTEs, X.25 packet 
  1031. mode DTEs and V\(hySeries interface terminals) to access from an ISDN one 
  1032. or more of 
  1033. the bearer services described in this Recommendation.
  1034. .RT
  1035. .sp 1P
  1036. .LP
  1037. 4.3
  1038.     \fIInterworking with circuit mode services\fR 
  1039. .sp 9p
  1040. .RT
  1041. .PP
  1042. Other service interworking configurations (e.g. with a CSPDN, or
  1043. between different bearer services within an ISDN) may also need to be
  1044. considered.
  1045. .bp
  1046. .RT
  1047. .sp 2P
  1048. .LP
  1049. \fB5\fR     \fBSupport of OSI connection\(hyoriented network layer service\fR 
  1050. .sp 1P
  1051. .RT
  1052. .PP
  1053. In the interworking between an ISDN offering any of the bearer
  1054. services described in this Recommendation and X.25\(hybased service offered 
  1055. either by an ISDN or a PSPDN, an interworking function (IWF) is required. 
  1056. .PP
  1057. To support network layer service (Rec.\ X.213) when the
  1058. bearer service used is one of the bearer services described in this
  1059. Recommendation, the use of additional end system functionality may be required 
  1060. and end\(hyto\(hyend (i.e.\ TE\(hyto\(hyTE or TE\(hyto\(hyIWF) compatibility 
  1061. must be ensured. 
  1062. .PP
  1063. Annex C contains requirements for the support of network layer service 
  1064. (Rec.\ X.213). 
  1065. .RT
  1066. .sp 2P
  1067. .LP
  1068. \fB6\fR     \fBApplications\fR 
  1069. .sp 1P
  1070. .RT
  1071. .PP
  1072. Packet mode bearer services described in this Recommendation aim at data 
  1073. services up to 2\ Mbit/s. Within this broad category, some specific 
  1074. applications are as follows:
  1075. .RT
  1076. .LP
  1077.     1)
  1078.     \fIBlock interactive data applications\fR 
  1079. .LP
  1080.     An example of a block interactive application would be high
  1081. resolution graphics (e.g.\ high resolution videotex, CAD/CAM). The main
  1082. characteristics of this type of application are low delays [e.g.\ approximately 
  1083. less than . |  | \ ms (the exact value is for further study)] and throughput 
  1084. approximately in the range of 500\ kbit/s to 2048\ kbit/s.
  1085. .LP
  1086.     2)
  1087.     \fIFile transfer\fR 
  1088. .LP
  1089.      The file transfer application is intended to cater for large file transfer 
  1090. requirements. Transit delay is not as critical for this application as 
  1091. it is for example in the first application. Higher throughput (e.g.\ 16\ 
  1092. kbit/s to 2048\ kbit/s) might be necessary in order to produce reasonable 
  1093. transfer 
  1094. times for large files.
  1095. .LP
  1096.     3)
  1097.     \fIMultiplexed low bit rate\fR 
  1098. .LP
  1099.      The multiplexed low bit rate application exploits the multiplexing capabilities 
  1100. of the layer\ 2 protocol in order to provide an economical access arrangement 
  1101. for a large group of low bit rate applications. The low bit rate 
  1102. sources should be multiplexed onto any ISDN\(hychannel by an NT function which
  1103. could take the form of a LAN, PABX, or Centrex. The delay requirements 
  1104. are in the area of  |  |  | \ ms (the exact value is for further study) 
  1105. and the throughput within the range of 16\ kbit/s to 2048\ kbit/s. 
  1106. .LP
  1107.     4)
  1108.     \fICharacter\(hyinteractive traffic\fR 
  1109. .LP
  1110.      An example of a character\(hyinteractive traffic is text editing. The 
  1111. main characteristics of this type of applications are short frames, low 
  1112. delays and low throughput. 
  1113. .PP
  1114. Identification of additional applications and their
  1115. characteristics (e.g.\ delay, throughput,\ etc.) for bearer services described 
  1116. in this Recommendation are desirable for the complete definition of the 
  1117. service 
  1118. requirements.
  1119. \v'1P'
  1120. .ce 1000
  1121. ANNEX\ A
  1122. .ce 0
  1123. .ce 1000
  1124. (to Recommendation I.122)
  1125. .sp 9p
  1126. .RT
  1127. .ce 0
  1128. .ce 1000
  1129. \fBFurther service\(hyrelated information\fR 
  1130. .sp 1P
  1131. .RT
  1132. .ce 0
  1133. .LP
  1134. A.1
  1135.     \fIIntroduction\fR 
  1136. .sp 1P
  1137. .RT
  1138. .PP
  1139. This Annex contains further service related information on the
  1140. I.122 based bearer services. The intent of this Annex is to clarify and
  1141. supplement the service descriptions given in the main body of this
  1142. Recommendation. Note that the information given in this Annex should not be
  1143. interpreted as material that completes the service descriptions of the 
  1144. bearer services given in this Recommendation. 
  1145. .bp
  1146. .RT
  1147. .sp 2P
  1148. .LP
  1149. A.2
  1150.     \fIService related information\fR 
  1151. .sp 1P
  1152. .RT
  1153. .sp 1P
  1154. .LP
  1155. A.2.1
  1156.     \fIFrame relaying 1\fR 
  1157. .sp 9p
  1158. .RT
  1159. .PP
  1160. The U\(hyplane configuration for this service is shown in
  1161. Figure\ A\(hy1/I.122.
  1162. .RT
  1163. .LP
  1164. .rs
  1165. .sp 24P
  1166. .ad r
  1167. \fBFigure A\(hy1/I.122, p.\fR 
  1168. .sp 1P
  1169. .RT
  1170. .ad b
  1171. .RT
  1172. .PP
  1173. Figure A\(hy1/I.122 shows the network in a generic way and
  1174. illustrates all U\(hyplane functions up to and including layer\ 3. In a 
  1175. specific 
  1176. network, frame relaying\ 1 may be implemented in one or more nodes, all other
  1177. nodes in the network providing only circuit\(hymode functions.
  1178. .PP
  1179. Frame relaying 1 can be offered on both, basic and primary rate
  1180. interfaces and on any ISDN channel (D, B, and H). Some restrictions (e.g.\ 
  1181. frame length) apply when in an end\(hyto\(hyend connection at least one 
  1182. of the access 
  1183. channels is the D\(hychannel (16\ kbit/s).
  1184. .PP
  1185. The bearer service provided by the network at the S/T reference point supports 
  1186. only the core functions defined in \(sc\ 3.1. A frame received by such 
  1187. a point is discarded if the frame does not meet the I.441 core format 
  1188. requirements (for example, if the frame is too long, has an unknown
  1189. label,\ etc.). Moreover, frames may be discarded due to internal network
  1190. conditions, or other reasons such as throughput enforcement.
  1191. .PP
  1192. In all other cases, the frame is relayed to one of the adjacent nodes according 
  1193. to the routing plan established at call set\(hyup time, or at 
  1194. subscription time (if the network is providing a permanent virtual circuit
  1195. service).
  1196. .PP
  1197. No additional U\(hyplane functions (see Note) visible to the users are
  1198. performed by the network. If needed by the application, additional functions
  1199. are performed end\(hyto\(hyend by layer(s) above the core functions.
  1200. .PP
  1201. \fINote\fR \ \(em\ Some additional auxiliary U\(hyplane functions such 
  1202. as reset or explicit congestion control may be defined if needed from the 
  1203. service 
  1204. perspective.
  1205. .bp
  1206. .RT
  1207. .sp 1P
  1208. .LP
  1209. A.2.2
  1210.     \fIFrame relaying 2\fR 
  1211. .sp 9p
  1212. .RT
  1213. .PP
  1214. The U\(hyplane configuration for this service is shown in
  1215. Figure\ A\(hy2/I.122.
  1216. .RT
  1217. .LP
  1218. .rs
  1219. .sp 20P
  1220. .ad r
  1221. \fBFigure A\(hy2/I.122, p.\fR 
  1222. .sp 1P
  1223. .RT
  1224. .ad b
  1225. .RT
  1226. .PP
  1227. Figure A\(hy2/I.122 shows the network in a generic way and
  1228. illustrates all U\(hyplane functions up to and including layer\ 3. In a 
  1229. specific 
  1230. network, frame relaying\ 2 may be implemented in one or more nodes, all other
  1231. nodes in the network providing only circuit\(hymode functions.
  1232. .PP
  1233. Frame relaying 2 can be offered on both, basic and primary rate
  1234. interfaces and on any ISDN channel (D, B, and H). Some restrictions (e.g.\ 
  1235. frame length) apply when in an end\(hyto\(hyend connection at least one 
  1236. of the access 
  1237. channels is the D\(hychannel (16\ kbit/s).
  1238. .PP
  1239. The bearer service provided by the network at the S/T reference point supports 
  1240. only the core functions defined in \(sc\ 3.1. A frame received by such 
  1241. a point is discarded if the frame does not meet the I.441 core format 
  1242. requirements (for example, if the frame is too long, has an unknown
  1243. label,\ etc.). Moreover, frames may be discarded due to internal network
  1244. conditions, or other possible reasons such as throughput enforcement.
  1245. .PP
  1246. The terminals operate end\(hyto\(hyend with the complete I.441* protocol. 
  1247. In all other cases, the frame is relayed to one of the adjacent nodes according 
  1248. to the routing plan established at call set\(hyup time, or at subscription 
  1249. time (if the network is providing a permanent virtual circuit service). 
  1250. .PP
  1251. No additional U\(hyplane functions (see Note) visible to the users are
  1252. performed by the network. If needed by the application, additional functions
  1253. are performed end\(hyto\(hyend by layer(s) above the core functions.
  1254. .PP
  1255. \fINote\fR \ \(em\ Some additional auxiliary U\(hyplane functions such 
  1256. as reset or explicit congestion control may be defined if needed from the 
  1257. service 
  1258. perspective.
  1259. .RT
  1260. .sp 1P
  1261. .LP
  1262. A.2.3
  1263.     \fIFrame switching\fR 
  1264. .sp 9p
  1265. .RT
  1266. .PP
  1267. The U\(hyplane configuration for this service is shown in
  1268. Figure\ A\(hy3/I.122.
  1269. .RT
  1270. .PP
  1271. Figure A\(hy3/I.122 shows the network in a generic way and
  1272. illustrates all functions up to and including layer\ 3. In a specific
  1273. network, frame switching must be implemented in at least one node in the
  1274. network.
  1275. .bp
  1276. .RT
  1277. .LP
  1278. .rs
  1279. .sp 15P
  1280. .ad r
  1281. \fBFigure A\(hy3/I.122, p.\fR 
  1282. .sp 1P
  1283. .RT
  1284. .ad b
  1285. .RT
  1286. .PP
  1287. Frame switching can be offered on both basic and primary rate
  1288. interfaces and on any ISDN channel (D, B, and H). Some restrictions (e.g.\ 
  1289. frame length) apply when in an end\(hyto\(hyend connection at least one 
  1290. of the access 
  1291. channels is the D\(hychannel (16\ kbit/s).
  1292. .PP
  1293. The bearer service provided by the network at the S/T reference point supports 
  1294. the full Recommendation\ I.441 function. Received frames that satisfy the 
  1295. Recommendation\ I.441 procedure are passed on to an adjacent node according 
  1296. to a routine plan established at call set\(hyup time, or at subscription 
  1297. time. 
  1298. .PP
  1299. No additional U\(hyplane functions visible to the users are performed in 
  1300. the network. If needed by the application, additional functions are performed 
  1301. end\(hyto\(hyend by layer(s) above layer\ 2. 
  1302. .RT
  1303. .sp 1P
  1304. .LP
  1305. A.2.4
  1306.     \fIX.25\(hybased additional packet mode\fR 
  1307. .sp 9p
  1308. .RT
  1309. .PP
  1310. The U\(hyplane configuration can comprise several nodes having layer 1, 
  1311. layer 2, and layer\ 3 functions as is shown in Figure\ A\(hy4/I.122. 
  1312. Figure\ A\(hy4/I.122 shows the network in a generic way and illustrates all
  1313. functions up to and including layer\ 3. Other configurations with nodes 
  1314. making use only of the core aspects of Recommendation\ I.441 as defined 
  1315. in \(sc\ 3.1 of 
  1316. Recommendation\ I.122 are possible.
  1317. .RT
  1318. .LP
  1319. .rs
  1320. .sp 17P
  1321. .ad r
  1322. \fBFigure A\(hy4/I.122, p.\fR 
  1323. .sp 1P
  1324. .RT
  1325. .ad b
  1326. .RT
  1327. .LP
  1328. .bp
  1329. .PP
  1330. X\(hy25\(hybased additional packet mode service can be offered on both 
  1331. the basic and primary rate ISDN access interfaces and on any ISDN channel 
  1332. (D, B, 
  1333. and H). Some restrictions (e.g.\ packet length) apply when in an end\(hyto\(hyend 
  1334. connection at least one of the access channels is the D\(hychannel (16\ 
  1335. kbit/s). 
  1336. .PP
  1337. The bearer service provided by the network at the S/T reference point supports 
  1338. the full Recommendation\ I.441 and the data transfer part of 
  1339. Recommendation\ X.25 PLP functions.
  1340. .PP
  1341. The U\(hyplane contains X.25\(hybased layer 3 functions and the C\(hyplane
  1342. procedures use Recommendation\ I.451 extended to transfer the parameters
  1343. necessary for the establishment and release of virtual circuits
  1344. (e.g.\ throughput class, window size,\ etc.). The capability to negotiate some
  1345. parameters must also be provided. Whether or not X.25 multiplexing is provided 
  1346. is for further study. 
  1347. .PP
  1348. X.25 PLP\(hyDTP consists of all X.25 PLP functions with the exception of 
  1349. the connection establishment and release functions, including user facilities 
  1350. (supplementary services). The exclusion of other X.25 PLP functions is 
  1351. for 
  1352. further study.
  1353. \v'1P'
  1354. .RT
  1355. .ce 1000
  1356. ANNEX\ B
  1357. .ce 0
  1358. .ce 1000
  1359. (to Recommendation I.122)
  1360. .sp 9p
  1361. .RT
  1362. .ce 0
  1363. .ce 1000
  1364. \fBGeneral arrangement for interworking between an ISDN\fR 
  1365. .sp 1P
  1366. .RT
  1367. .ce 0
  1368. .ce 1000
  1369. \fBwhere I.122 bearer services are requested\fR 
  1370. .ce 0
  1371. .ce 1000
  1372. \fBand an ISDN or a PSPDN providing service based on Recommendation X.25\fR 
  1373. .ce 0
  1374. .LP
  1375. B.1
  1376.     \fIPossible scenarios\fR 
  1377. .sp 1P
  1378. .RT
  1379. .PP
  1380. Figure B\(hy1/I.122 shows the interworking arrangements considered.
  1381. When the interworking function IWF logically belongs to the ISDN
  1382. (Recommendation\ I.122), interworking based on call control mapping takes 
  1383. place. In the case where the IWF logically belongs to the PSPDN (Recommendation\ 
  1384. X.25) or ISDN (Recommendation\ X.31), interworking based on either call 
  1385. control 
  1386. mapping or port access is possible. As shown in the figure, different
  1387. interfaces can be specified for the different reference points, depending on
  1388. whether the IWF logically belongs to the ISDN (Recommendation\ I.122), 
  1389. or to the PSPDN (Recommendation\ X.25) or ISDN (Recommendation\ X.31). 
  1390. .RT
  1391. .sp 1P
  1392. .LP
  1393. B.2
  1394.     \fIIWF logically belonging to ISDN (Recommendation I.122)\fR 
  1395. .sp 9p
  1396. .RT
  1397. .PP
  1398. To enable interworking, the I.122 bearer services, in conjunction with 
  1399. an IWF, should provide full support of the X.213 network layer services. 
  1400. The association of an ISDN (Recommendation\ I.122) with an IWF in such 
  1401. a manner could therefore be considered globally as a Type\ I subnetwork, 
  1402. in the sense 
  1403. defined in Recommendation\ X.300.
  1404. .PP
  1405. A PSPDN (Recommendation X.25) or an ISDN (Recommendation X.31) could also 
  1406. be considered as a Type\ I subnetwork. 
  1407. .PP
  1408. As specified in Recommendation X.300, the interworking arrangement
  1409. between two Type\ I subnetworks should be based on Recommendation\ X.75.
  1410. .RT
  1411. .sp 1P
  1412. .LP
  1413. B.3
  1414.     \fIIWF logically belonging to the PSPDN (Recommendation X.25)/ISDN\fR 
  1415. \fI(Recommendation X.31)\fR 
  1416. .sp 9p
  1417. .RT
  1418. .PP
  1419. The association of a PSPDN (Recommendation X.25)/ISDN
  1420. (Recommendation\ X.31) with an IWF together behaves like a user terminal
  1421. requesting I.122 service from an ISDN (Recommendation\ I.122). Therefore, the
  1422. interworking arrangement can be based on Recommendation\ I.122.
  1423. .PP
  1424. In this arrangement, interworking based on either call control mapping 
  1425. or port access is possible. When port access method is used, existing call 
  1426. control procedures in Recommendation\ X.25 are used for the control of 
  1427. virtual circuits. 
  1428. .bp
  1429. .RT
  1430. .LP
  1431. .rs
  1432. .sp 30P
  1433. .ad r
  1434. \fBFigure B\(hy1/I.122, p.\fR 
  1435. .sp 1P
  1436. .RT
  1437. .ad b
  1438. .RT
  1439. .ce 1000
  1440. ANNEX\ C
  1441. .ce 0
  1442. .ce 1000
  1443. (to Recommendation I.122)
  1444. .sp 9p
  1445. .RT
  1446. .ce 0
  1447. .ce 1000
  1448. \fBSupport of network layer service (X.213)\fR 
  1449. .sp 1P
  1450. .RT
  1451. .ce 0
  1452. .ce 1000
  1453. \fBin an ISDN offering additional packet mode bearer services\fR 
  1454. .ce 0
  1455. .PP
  1456. C.1
  1457. Network layer service can be provided by using the X.25\(hybased additional 
  1458. packet mode bearer service. In this case the mapping concerns 
  1459. enhanced Recommendations\ I.451 and X.25 data transfer functions. In the 
  1460. case of frame switching and frame relaying, the network layer service can 
  1461. be provided through the use of enhanced Recommendation\ I.451, with, in 
  1462. addition: 
  1463. .sp 1P
  1464. .RT
  1465. .LP
  1466.     a)
  1467.     additional end system functionality, or
  1468. .LP
  1469.     b)
  1470.     enhanced I.441 functions.
  1471. .sp 1P
  1472. .LP
  1473. C.2
  1474.     \fIC\(hyplane enhancements\fR 
  1475. .sp 9p
  1476. .RT
  1477. .PP
  1478. Recommendation I.451 should be enhanced so that the OSI network
  1479. service parameters can be paired with Recommendation\ I.451 messages and
  1480. information elements for all bearer services. Serveral enhancements to
  1481. Recommendation\ I.451 are needed to convey all connection establishment and
  1482. release primitives and parameters in relevant I.451 protocol elements.
  1483. .bp
  1484. .RT
  1485. .sp 1P
  1486. .LP
  1487. C.3
  1488.     \fIU\(hyplane enhancements\fR 
  1489. .sp 9p
  1490. .RT
  1491. .PP
  1492. For frame switching and frame relaying, there are two different
  1493. approaches for the mapping of data transfer primitives into protocol
  1494. elements:
  1495. .RT
  1496. .LP
  1497.     1)
  1498.     layer 3 protocol elements supported by a DTE specific
  1499. protocol which is transparent for the network (preferably X.25 PLP), and
  1500. .LP
  1501.     2)
  1502.     I.441 protocol elements enhanced to map directly into the
  1503. OSI network service data transfer primitives.
  1504. .PP
  1505. Further study is required for the selection and detailed
  1506. definition of one of the two options.
  1507. \v'1P'
  1508. .ce 1000
  1509. ANNEX\ D
  1510. .ce 0
  1511. .ce 1000
  1512. (to Recommendation I.122)
  1513. .sp 9p
  1514. .RT
  1515. .ce 0
  1516. .ce 1000
  1517. \fBCongestion control in frame relaying service\fR 
  1518. .sp 1P
  1519. .RT
  1520. .ce 0
  1521. .PP
  1522. \fINote\fR \ \(em\ This Annex does not cover congestion control in frame 
  1523. switching and X.25\(hybased additional packet mode bearer services. This 
  1524. is 
  1525. because in these services, there is termination of user data transfer protocol 
  1526. in the network and so existing mechanisms for congestion control can be 
  1527. used. 
  1528. .sp 1P
  1529. .RT
  1530. .sp 1P
  1531. .LP
  1532. D.1
  1533.     \fIGeneral objectives of\fR \fIcongestion control\fR 
  1534. .sp 9p
  1535. .RT
  1536. .PP
  1537. The term \*Qcongestion control\*U as used here refers to a set of
  1538. mechanisms incorporated to attain certain network performance objectives,
  1539. particularly in the peak periods, while optimizing or improving the network
  1540. resource requirements.
  1541. .RT
  1542. .LP
  1543.     1)
  1544.      The network should, with high probability, meet the Quality of Service 
  1545. in terms of throughput, delay and availability negotiated with the user. 
  1546. Therefore, the number of occurrences of user perceived congestion should 
  1547. be minimized. 
  1548. .LP
  1549.     2)
  1550.     Under heavy load, the network should not allow user
  1551. interference to the extent where one user can monopolize network resource 
  1552. usage at the expense of other users. 
  1553. .PP
  1554. Specific congestion control mechanisms to achieve these objectives are 
  1555. for further study. One possible approach of congestion control is presented 
  1556. below. 
  1557. .sp 1P
  1558. .LP
  1559. D.2
  1560.     \fIUser reaction to network congestion\fR 
  1561. .sp 9p
  1562. .RT
  1563. .PP
  1564. The network has no other direct control on the data flow of a user other 
  1565. than dropping frames. It does so without sending explicit congestion 
  1566. control messages to the user. Frame discard by a network may have charging
  1567. implications. This requires further study.
  1568. .PP
  1569. Users should reduce their information transfer rate when they perceive 
  1570. the impact of network congestion. Reduction of throughput by a user may 
  1571. well 
  1572. result in an increase of the effective throughput available to the user 
  1573. during congestion. 
  1574. .PP
  1575. It is suggested that a user of frame relaying 1 service implement some 
  1576. form of congestion\(hysensitive adaptation function that has the following 
  1577. characteristics:
  1578. .RT
  1579. .LP
  1580.     i)
  1581.     no blocking of data flow under normal conditions,
  1582. .LP
  1583.     ii)
  1584.     reduction to a lower throughput upon detection of network   congestion,
  1585. .LP
  1586.     iii)
  1587.      progressive increase to the maximum negotiated throughput upon congestion 
  1588. abatement. 
  1589. .PP
  1590. For frame relaying 2 service, the user is required to implement
  1591. the above congestion\(hysensitive adaptation function through the use of the
  1592. windowing mechanism in Recommendation\ I.441. In this case, the user will 
  1593. base the detection of congestion on events available in the I.441 elements 
  1594. of 
  1595. procedure (e.g.\ receipt of a REJECT frame, detection of frame loss,\ etc.). 
  1596. The user dynamically adjusts its window size in accordance with network 
  1597. congestion condition. 
  1598. .bp
  1599. .sp 1P
  1600. .LP
  1601. D.3
  1602.     \fIControl action by the network congestion\fR 
  1603. .sp 9p
  1604. .RT
  1605. .PP
  1606. Users of frame relaying services should reduce their information
  1607. transfer rate when they perceive the impact of network congestion (see 
  1608. \(sc\ 2). 
  1609. But the network cannot rely solely on the user's behaviour to control network 
  1610. congestion. This is the case for both frame relaying\ 1 and frame relaying\ 
  1611. 2 
  1612. services.
  1613. .PP
  1614. The network should monitor the throughput of each call/interface and exercise 
  1615. a frame discard strategy under congestion conditions, for those 
  1616. calls/interfaces that exceed their negotiated throughput. However, because
  1617. congestion can occur even when the calls do not exceed their negotiated
  1618. throughput (e.g.\ network failures), the network should discard frames 
  1619. in a way that assures some fairness among users. 
  1620. .PP
  1621. The selection of mechanism(s) which may be used by the network for
  1622. this purpose are for further study.
  1623. .RT
  1624. .LP
  1625. .rs
  1626. .sp 43P
  1627. .ad r
  1628. Blanc
  1629. .ad b
  1630. .RT
  1631. .LP
  1632. .bp
  1633. .sp 1P
  1634. .ce 1000
  1635. \v'3P'
  1636. SECTION\ 3
  1637. .ce 0
  1638. .sp 1P
  1639. .ce 1000
  1640. \fBGENERAL MODELLING METHODS\fR 
  1641. .ce 0
  1642. .sp 1P
  1643. .sp 2P
  1644. .LP
  1645. \fBRecommendation\ I.130\fR 
  1646. .RT
  1647. .sp 2P
  1648. .ce 1000
  1649. \fBMETHOD FOR THE CHARACTERIZATION OF TELECOMMUNICATION\fR 
  1650. .EF '%    Fascicle\ III.7\ \(em\ Rec.\ I.130''
  1651. .OF '''Fascicle\ III.7\ \(em\ Rec.\ I.130    %'
  1652. .ce 0
  1653. .ce 1000
  1654. \fBSERVICES SUPPORTED BY AN ISDN AND NETWORK\fR 
  1655. .ce 0
  1656. .sp 1P
  1657. .ce 1000
  1658. \fBCAPABILITIES OF AN ISDN\fR 
  1659. .ce 0
  1660. .sp 1P
  1661. .ce 1000
  1662. \fI(Melbourne, 1988)\fR 
  1663. .sp 9p
  1664. .RT
  1665. .ce 0
  1666. .sp 1P
  1667. .LP
  1668. \fB1\fR     \fBGeneral considerations\fR 
  1669. .sp 1P
  1670. .RT
  1671. .PP
  1672. The concept and the principles of ISDNs are described in
  1673. Recommendation\ I.120. The purpose of this Recommendation is to provide 
  1674. a method for the characterization of telecommunication services (including 
  1675. supplementary services) and a definition of the needed network capabilities 
  1676. in an ISDN, in 
  1677. order to support the identified services.
  1678. .PP
  1679. The main objectives are:
  1680. .RT
  1681. .LP
  1682.     a)
  1683.     to give a common framework and tools to be adopted for
  1684. service description;
  1685. .LP
  1686.     b)
  1687.     to show how, starting from the service definition, it is
  1688. possible to define protocols and network resources for providing such
  1689. services;
  1690. .LP
  1691.     c)
  1692.     to make reference to those Recommendations which are
  1693. relevant to the above two points.
  1694. .sp 2P
  1695. .LP
  1696. \fB2\fR     \fBStructure and application of the overall method\fR 
  1697. .sp 1P
  1698. .RT
  1699. .PP
  1700. The method is divided into three main stages of activity: service aspects 
  1701. (stage\ 1), functional network aspects (stage\ 2) and network 
  1702. implementation aspects (stage\ 3).
  1703. .PP
  1704. Within each stage a number of steps have been identified, as shown in Figure\ 
  1705. 1/I.130. In principle, the application of the method is sequential, 
  1706. stage\ 1 given the service description from the user point of view, stage\ 2
  1707. offering an intermediate view of what happens at the user\(hynetwork interface 
  1708. and inside the network between different exchanges, and stage\ 3 giving 
  1709. the actual switching and service nodes descriptions, as well as protocols 
  1710. and format to be adopted. 
  1711. .PP
  1712. In order to classify and relate the various Recommendations relevant to 
  1713. the method, a three level structure is used where each level applies to 
  1714. the three above\(hymentioned stages. 
  1715. .PP
  1716. Level\ 1 is a description of the overall method, and is contained in
  1717. this Recommendation.
  1718. .PP
  1719. Level\ 2 identifies and defines the tools for the work within each
  1720. stage. Examples of these tools are frameworks for service prose descriptions, 
  1721. libraries of pre\(hydefined functions, graphical conventions,\ etc. All 
  1722. these tools are covered by Recommendations. 
  1723. .PP
  1724. Level\ 3 is the actual application of the method to each individual
  1725. service and is contained in various Recommendations.
  1726. .PP
  1727. The application of the method for stage\ 1 results in a description of 
  1728. the service. Stage\ 2 results in one or more implementation independent 
  1729. scenarios, and stage\ 3 results in a set of protocol and switching
  1730. Recommendations needed to realize the service for each scenario.
  1731. .PP
  1732. Figure\ 2/I.130 illustrates the concept of levels in relation to
  1733. various Recommendations relevant to the method.
  1734. .bp
  1735. .RT
  1736. .LP
  1737. .rs
  1738. .sp 47P
  1739. .ad r
  1740. \fBFigure 1/I.130, p. 8\fR 
  1741. .sp 1P
  1742. .RT
  1743. .ad b
  1744. .RT
  1745. .LP
  1746. .bp
  1747. .LP
  1748. .rs
  1749. .sp 47P
  1750. .ad r
  1751. \fBFigure 2/I.130, p. 9\fR 
  1752. .sp 1P
  1753. .RT
  1754. .ad b
  1755. .RT
  1756. .LP
  1757. .bp
  1758. .sp 2P
  1759. .LP
  1760. \fB3\fR     \fBDescription of the method\fR 
  1761. .sp 1P
  1762. .RT
  1763. .PP
  1764. As referred to in \(sc\ 2 above, there are three stages of the method as 
  1765. follows: 
  1766. .PP
  1767. Stage\ 1 is an overall service description from the user's standpoint.
  1768. .PP
  1769. Stage\ 2 is an overall description of the organization of the network functions 
  1770. to map service requirements into network capabilities. 
  1771. .PP
  1772. Stage\ 3 is the definition of switching and signalling capabilities
  1773. needed to support services defined in stage\ 1.
  1774. .PP
  1775. Each stage consists of several steps.
  1776. .RT
  1777. .sp 1P
  1778. .LP
  1779. 3.1
  1780.     \fIStage 1\fR 
  1781. .sp 9p
  1782. .RT
  1783. .PP
  1784. Stage\ 1 is an overall service description from the user's point of view, 
  1785. but does not deal with the details of the human interface itself. The 
  1786. stage\ 1 service description is independent of the amount of functionality in
  1787. the user's terminal, other than that required to provide the human interface. 
  1788. For example the conference calling service description is designed to be 
  1789. independent of whether the conference bridge is in the terminal, in the 
  1790. serving exchange or elsewhere. 
  1791. .PP
  1792. The steps in stage\ 1 are:
  1793. .RT
  1794. .LP
  1795.     \fIStep 1.1\ \(em\ Service prose definition and description\fR 
  1796. .LP
  1797.      This step describes the service in terms of the perceptions of the user 
  1798. receiving the service and any other users involved in the service. It 
  1799. describes events in a generic term which does not constrain terminal or 
  1800. network design. It is intended to allow an understanding of the service 
  1801. without regard to implementation. The description should include operational, 
  1802. control, 
  1803. interworking and administrative aspects as well as interactions with other
  1804. sevices. A detailed format and list of definitions for terms used for service 
  1805. prose definition and description is contained in Recommendation\ I.210. 
  1806. .LP
  1807.     \fIStep 1.2\ \(em\ Static description of the service using attributes\fR 
  1808. .LP
  1809.      The static, that is, time\(hyindependent, aspects of a service can, in 
  1810. some cases, be efficiently described by attributes. An attribute is a 
  1811. characteristic or functional description which is common to several services
  1812. and therefore needs to be described in detail only once. Subsequently, 
  1813. it can be referred to by a name or other designation. Within the scope 
  1814. of an attribute definition there may be multiple parameters or identified 
  1815. functional variations which are called attribute values. 
  1816. .LP
  1817.     The attribute technique is described more fully in
  1818. Recommendation\ I.140. It contains an outline of the technique and definitions 
  1819. of attributes and attributes values, valid for both services and connection 
  1820. types. The attributes and attribute values identified for services can 
  1821. be found in Rec.\ I.210 (Annexes\ B and\ C) for bearer services and for 
  1822. teleservices. The use of the attribute technique in the description of 
  1823. supplementary services 
  1824. is for further study.
  1825. .LP
  1826.     \fIStep 1.3\ \(em\ Dynamic description of the service using\fR 
  1827. \fIgraphic means\fR 
  1828. .LP
  1829.      The dynamic description of a service contains all the information that 
  1830. is sent and received by the user from activation invocation of the service 
  1831. to completion of the service. The information is presented in the form 
  1832. of an 
  1833. overall Specification and Description Language\ (SDL) diagram. An overall SDL
  1834. diagram is a flow chart which identifies all possible actions relevant 
  1835. to the service as perceived by the user. It treats the network as a single 
  1836. entity, 
  1837. that is, no information flows within the network are considered. The method 
  1838. of using the overall SDL diagrams for service description is given in 
  1839. Recommendation\ I.210, Annex\ D.
  1840. .sp 1P
  1841. .LP
  1842. 3.2
  1843.     \fIStage 2\fR 
  1844. .sp 9p
  1845. .RT
  1846. .PP
  1847. Stage 2 identifies the functional capabilities and the information flows 
  1848. needed to support the service as described in stage\ 1. The stage\ 2 
  1849. description will also include user operations not directly associated with a
  1850. call (e.g.\ user change of call forwarding parameters via his sevice interface) 
  1851. as described in stage\ 1. Furthermore, it identifies various possible physical 
  1852. locations for the functional capabilities. The output of stage\ 2 which 
  1853. is 
  1854. signalling system independent is used as an input to the design of signalling 
  1855. system and exchange switching Recommendations. 
  1856. .bp
  1857. .PP
  1858. The steps in stage\ 2 are:
  1859. .RT
  1860. .LP
  1861.     \fIStep 2.1\ \(em\ Derivation of a functional model\fR 
  1862. .LP
  1863.     A functional model is derived for each basic and for each
  1864. supplementary service. The functions required to provide the service are
  1865. grouped into functional entities. The functional model is the aggregate 
  1866. of the functional entities and their relationships. The concept of a functional 
  1867. entity is contained in the ISDN functional principles Recommendation\ (I.310). 
  1868. In the case of supplementary services the relationship between the supplementary 
  1869. service and the basic service is shown by a composite functional model.
  1870. .LP
  1871.     \fIStep 2.2\ \(em\ Information flow diagrams\fR 
  1872. .LP
  1873.      The distribution of the functions needed to provide a service as defined 
  1874. by the functional model requires that interactions be defined between functional 
  1875. entities. Such an interaction is referred to as an \*Q 
  1876. information  flow
  1877. \*U and has a name descriptive of the intent of the information flow.
  1878. Information flow diagrams are created for successful operation and may be
  1879. created as appropriate for other cases. The semantic meaning and information
  1880. content of each information flow is determined.
  1881. .LP
  1882.     \fIStep 2.3\ \(em\ SDL diagrams for functional entities\fR 
  1883. .LP
  1884.      The functions performed within a functional entity are identified and 
  1885. represented in the form of a Specification and Description Language (SDL) 
  1886. diagram. The inputs and outputs of the SDL diagram are to and from the 
  1887. users as described in stage\ 1 and are information flows to and from other 
  1888. functional 
  1889. entities.
  1890. .LP
  1891.      SDL diagrams are defined for each functional entity based on the information 
  1892. flows defined for the successful operation of the service. The SDL diagram 
  1893. also covers the unsuccessful cases. 
  1894. .LP
  1895.     \fIStep 2.4\ \(em\ Functional entity actions\fR 
  1896. .LP
  1897.      The actions performed within a functional entity are represented as a 
  1898. list, or sequence, of functional entity actions\ (FEAs) in prose form. 
  1899. These form the basis for understanding the meaning of the information
  1900. flows and provide a basis for the stage\ 3 switching Recommendations.
  1901. .LP
  1902.     \fINote\fR \ \(em\ The relationship between the FEAs and the elementary
  1903. functions\ (EFs), as listed in Recommendation\ I.310 is for further study.
  1904. .LP
  1905.     \fIStep 2.5\ \(em\ Allocation of functional entities to physical\fR 
  1906. \fIlocations\fR 
  1907. .LP
  1908.     In this step, the functional entities and information flows
  1909. identified in previous steps are allocated to specific types of physical
  1910. locations,\ e.g. a PABX or an exchange. Each allocation is called a scenario.
  1911. The relationship supported between two functional entities located in different 
  1912. physical locations must be realized wihin protocol(s) supported between 
  1913. those locations. 
  1914. .LP
  1915.      The detailed procedures and formats used and the concepts needed for 
  1916. the stage\ 2 description can be found in Recommendations\ Q.65 and I.310. 
  1917. .sp 1P
  1918. .LP
  1919. 3.3
  1920.     \fIStage 3\fR 
  1921. .sp 9p
  1922. .RT
  1923. .PP
  1924. In stage\ 3 the information flow and SDL diagrams from the stage\ 2 output 
  1925. form the basis for producing the signalling system protocol 
  1926. Recommendations and the switching Recommendations.
  1927. .PP
  1928. The steps in stage\ 3 will need to be repeated for each service where, 
  1929. because of different allocations of functional entities to physical locations, 
  1930. different protocols and procedures are needed. 
  1931. .PP
  1932. The steps in stage\ 3 are:
  1933. .RT
  1934. .LP
  1935.     \fIStep 3.1\ \(em\ Protocols and formats\fR 
  1936. .LP
  1937.     The messages needed to support the information flows and the
  1938. modifications to existing information flows between the nodes are identified
  1939. and the detailed message elements and procedures are designed into the 
  1940. relevant signalling systems. 
  1941. .LP
  1942.     \fIStep 3.2\ \(em\ Switching and service nodes\fR 
  1943. .LP
  1944.     The requirements identified for switching functions (functional
  1945. entity actions) are incorporated into the switching Recommendations
  1946. (Q.500\(hySeries).
  1947. .bp
  1948. .LP
  1949. \fBMONTAGE : PAGE 84 = PAGE BLANCHE\fR 
  1950. .sp 1P
  1951. .RT
  1952. .LP
  1953. .bp
  1954. .sp 1P
  1955. .ce 1000
  1956. \v'3P'
  1957. SECTION\ 4
  1958. .ce 0
  1959. .sp 1P
  1960. .ce 1000
  1961. \fBTELECOMMUNICATION NETWORK AND SERVICE ATTRIBUTES\fR \v'1P'
  1962. .ce 0
  1963. .sp 1P
  1964. .sp 2P
  1965. .LP
  1966. \fBRecommendation\ I.140\fR 
  1967. .RT
  1968. .sp 2P
  1969. .LP
  1970. .EF '%    Fascicle\ III.7\ \(em\ Rec.\ I.140''
  1971. .OF '''Fascicle\ III.7\ \(em\ Rec.\ I.140    %'
  1972. .ce 1000
  1973. \fBATTRIBUTE TECHNIQUE FOR THE CHARACTERIZATION OF\fR 
  1974. .ce 0
  1975. .ce 1000
  1976. \fBTELECOMMUNICATION SERVICES SUPPORTED BY AN\fR 
  1977. .ce 0
  1978. .sp 1P
  1979. .ce 1000
  1980. \fBISDN AND NETWORK CAPABILITIES OF AN ISDN\fR 
  1981. .ce 0
  1982. .sp 1P
  1983. .ce 1000
  1984. \fI(former Recommendation I.130 of the Red Book;\fR 
  1985. .sp 9p
  1986. .RT
  1987. .ce 0
  1988. .sp 1P
  1989. .ce 1000
  1990. \fIamended at Melbourne, 1988)\fR 
  1991. .ce 0
  1992. .sp 1P
  1993. .LP
  1994. \fB1\fR     \fBGeneral considerations\fR 
  1995. .sp 1P
  1996. .RT
  1997. .PP
  1998. The purpose of this Recommendation is to introduce the attribute
  1999. technique and to describe attributes and list attribute values. Attributes 
  2000. are used in the characterization of services and network capabilities provided 
  2001. by an ISDN. The attribute technique can also be used to describe the salient 
  2002. features of other objects of study in telecommunications, e.g.\ charging.
  2003. .PP
  2004. This Recommendation (in the general\ I.100\(hySeries) will act as a
  2005. library of all attributes and attribute values used in other
  2006. I\(hySeries\ Recommendations. The inclusion of a particular attribute value 
  2007. in this Recommendation does not mean that this particular object is being 
  2008. recommended by CCITT, but that it is a potential attribute (or attribute 
  2009. value) which may be used in a particular Recomendation in the\ I\(hySeries 
  2010. (e.g.\ to describe a 
  2011. CCITT\(hyrecommended service).
  2012. .PP
  2013. Annex\ A includes all attributes and their values so far identified and 
  2014. defined. 
  2015. .RT
  2016. .sp 2P
  2017. .LP
  2018. \fB2\fR     \fBAttribute technique\fR 
  2019. .sp 1P
  2020. .RT
  2021. .sp 1P
  2022. .LP
  2023. 2.1
  2024.     \fIOutline of the technique\fR 
  2025. .sp 9p
  2026. .RT
  2027. .PP
  2028. This technique is used to describe objects in a structured, simple manner 
  2029. and to highlight the important aspects of the object. In order to be 
  2030. able to identify comparable objects, e.g.\ bearer services, the general 
  2031. concept of the object is broken down in a number of salient features. The 
  2032. salient 
  2033. features are termed \fIattributes\fR .  | ach attribute is independent 
  2034. of the others so that a change in the value of one will not affect the 
  2035. others. To describe a particular object the attributes are assigned values 
  2036. which identify that 
  2037. object.
  2038. .PP
  2039. It is not always necessary or useful to describe an object in great
  2040. detail and so attributes have been graded into three levels:
  2041. .RT
  2042. .LP
  2043.     \(em
  2044.     dominant attributes
  2045. : these define a sub\(hyset
  2046. containing similar objects, this sub\(hyset is termed a class or category;
  2047. .LP
  2048.     \(em
  2049.     secondary attributes
  2050. : these define a particular
  2051. object; and
  2052. .LP
  2053.     \(em
  2054.     qualifying attributes
  2055. : these define variants of an
  2056. object.
  2057. .PP
  2058. Characterization of attributes should be used in the I\(hySeries of Recommendations 
  2059. when appropriate. 
  2060. .bp
  2061. .sp 1P
  2062. .LP
  2063. 2.2
  2064.     \fIBasic rules\fR 
  2065. .sp 9p
  2066. .RT
  2067. .LP
  2068.     \(em
  2069.     Each attribute is assigned a name and definition.
  2070. .LP
  2071.     \(em
  2072.      Some attributes may apply to only one object, others may be applicable 
  2073. to several objects. In this case the same attribute name is used. 
  2074. .LP
  2075.     \(em
  2076.     A given value should have the same name and definition in all Recommendations.
  2077. .LP
  2078.     \(em
  2079.      Depending on the nature of the object described, a particular attribute 
  2080. may need to be used more than once. 
  2081. .LP
  2082.     \(em
  2083.     Each attribute should be described by three perspectives;
  2084. generic, service and network.
  2085. .sp 2P
  2086. .LP
  2087. 2.3
  2088.     \fIAttribute lists\fR 
  2089. .sp 1P
  2090. .RT
  2091. .sp 1P
  2092. .LP
  2093. 2.3.1
  2094.     \fIGeneric attributes\fR 
  2095. .sp 9p
  2096. .RT
  2097. .LP
  2098.     Information transfer mode
  2099. .LP
  2100.     Information transfer rate
  2101. .LP
  2102.     Information transfer capability
  2103. .LP
  2104.     Establishment
  2105. .LP
  2106.     Symmetry
  2107. .LP
  2108.     Configuration
  2109. .LP
  2110.     Structure
  2111. .LP
  2112.     Channel (rate)
  2113. .LP
  2114.     Control protocol
  2115. .LP
  2116.     Information transfer protocol
  2117. .LP
  2118.     Performance
  2119. .LP
  2120.     Interworking
  2121. .LP
  2122.     Operations
  2123. .LP
  2124.     Type of user information
  2125. .LP
  2126.     High layer protocol
  2127. .PP
  2128. \fINote\fR \ \(em\ This list will be completed according to further results 
  2129. on studies of connectionless, multi\(hymedia, broadband and mobile services. 
  2130. .sp 2P
  2131. .LP
  2132. 2.3.2
  2133.     \fIService attributes\fR 
  2134. .sp 1P
  2135. .RT
  2136. .sp 1P
  2137. .LP
  2138. 2.3.2.1
  2139.     \fIBearer services\fR 
  2140. .sp 9p
  2141. .RT
  2142. .LP
  2143.     1
  2144.     Information transfer mode
  2145. .LP
  2146.     2
  2147.     Information transfer rate
  2148. .FS
  2149. Service information transfer
  2150. rate considered at the access point.
  2151. .FE
  2152. .LP
  2153.     3
  2154.     Information transfer capability
  2155. .LP
  2156.     4
  2157.     Structure
  2158. .LP
  2159.     5
  2160.     Establishment of communication
  2161. .LP
  2162.     6
  2163.     Symmetry
  2164. .LP
  2165.     7
  2166.     Communication configuration
  2167. .LP
  2168.     8
  2169.     Access channel and rate
  2170. .LP
  2171.     9\(hy1
  2172.     Signalling access protocol layer 1
  2173. .LP
  2174.     9\(hy2
  2175.     Signalling access protocol layer 2
  2176. .LP
  2177.     9\(hy3
  2178.     Signalling access protocol layer 3
  2179. .LP
  2180. Information access protocol (layer\ 1\(hy3) at the access point.
  2181. .FE
  2182.     9\(hy4
  2183.     Information access protocol layer 1
  2184. .LP
  2185.     9\(hy5
  2186.     Information access protocol layer 2
  2187. .LP
  2188.     9\(hy6
  2189.     Information access protocol layer 3
  2190. .LP
  2191.     10
  2192.     Supplementary services provided
  2193. .LP
  2194.     11
  2195.     Quality of service
  2196. .LP
  2197.     12
  2198.     Interworking possibilities
  2199. .LP
  2200.     13
  2201.     Operational and commercial
  2202. .LP
  2203. .sp 1
  2204. .bp
  2205. .sp 1P
  2206. .LP
  2207. 2.3.2.2
  2208.     \fITeleservices\fR 
  2209. .sp 9p
  2210. .RT
  2211. .PP
  2212. 1, 2, 3, 4, 5, 6, 7, 8, 9\(hy1, 9\(hy2, 9\(hy3, 9\(hy4, 9\(hy5, 9\(hy6:
  2213. refer to \(sc\ 2.3.2.1.
  2214. .RT
  2215. .LP
  2216.     10
  2217.     Type of user information
  2218. .LP
  2219.     11
  2220.     Layer 4 protocol
  2221. .LP
  2222.     12
  2223.     Layer 5 protocol
  2224. .LP
  2225.     13
  2226.     Layer 6 protocol
  2227. .LP
  2228.     14
  2229.     Layer 7 protocol
  2230. .LP
  2231.     15
  2232.     Supplementary services provided
  2233. .LP
  2234.     16
  2235.     Quality of service
  2236. .LP
  2237.     17
  2238.     Interworking possibilities
  2239. .LP
  2240.     18
  2241.     Operational and commercial
  2242. .sp 1P
  2243. .LP
  2244. 2.3.2.3
  2245.     \fISupplementary services\fR 
  2246. .sp 9p
  2247. .RT
  2248. .PP
  2249. For further study.\fR 
  2250. .RT
  2251. .sp 1P
  2252. .LP
  2253. 2.3.2.4
  2254.     \fICharging\fR 
  2255. .sp 9p
  2256. .RT
  2257. .PP
  2258. For further study.
  2259. .RT
  2260. .sp 2P
  2261. .LP
  2262. 2.3.3
  2263.     \fINetwork attributes\fR 
  2264. .sp 1P
  2265. .RT
  2266. .sp 1P
  2267. .LP
  2268. 2.3.3.1
  2269.     \fIConnection types\fR 
  2270. .sp 9p
  2271. .RT
  2272. .LP
  2273.     1
  2274.     Information transfer mode
  2275. .LP
  2276.     2
  2277.     Information transfer rate
  2278. .FS
  2279. Information transfer rate is
  2280. considered between access points.
  2281. .FE
  2282. .LP
  2283.     3
  2284.     Information transfer susceptance
  2285. .LP
  2286.     4
  2287.     Establishment of communication
  2288. .LP
  2289.     5
  2290.     Symmetry
  2291. .LP
  2292.     6
  2293.     Connection configuration
  2294. .LP
  2295.     7
  2296.     Structure
  2297. .LP
  2298.     8
  2299.     Channel (rate)
  2300. .LP
  2301.     9
  2302.     Connection control protocol
  2303. .LP
  2304.     10
  2305.     Information transfer coding/protocol
  2306. .FS
  2307. Information
  2308. transfer protocol is considered between access points.
  2309. .FE
  2310. .LP
  2311.     11
  2312.     Network performance
  2313. .LP
  2314.     12
  2315.     Network interworking
  2316. .LP
  2317.     13
  2318.     Operations and management
  2319. .sp 1P
  2320. .LP
  2321. 2.3.3.2
  2322.     \fIConnection elements\fR 
  2323. .sp 9p
  2324. .RT
  2325. .LP
  2326.     1
  2327.     Information transfer mode
  2328. .LP
  2329.     2
  2330.     Information transfer rate
  2331. .LP
  2332.     3
  2333.     Information transfer susceptance
  2334. .LP
  2335.     4
  2336.     Establishment of communication
  2337. .LP
  2338.     5
  2339.     Symmetry
  2340. .LP
  2341.     6
  2342.     Connection configuration
  2343. .LP
  2344.     7
  2345.     Structure
  2346. .LP
  2347.     8
  2348.     Channel (rate)
  2349. .LP
  2350.     9
  2351.     Connection control protocol
  2352. .LP
  2353.     10
  2354.     Information transfer coding/protocol
  2355. .LP
  2356.     11
  2357.     Network performance
  2358. .LP
  2359.     12
  2360.     Network interworking
  2361. .LP
  2362.     13
  2363.     Operations and management
  2364. .LP
  2365. .sp 1
  2366. .bp
  2367. .sp 1P
  2368. .LP
  2369. 2.3.3.3
  2370.     \fIOther network entities\fR 
  2371. .sp 9p
  2372. .RT
  2373. .PP
  2374. The definition of attributes for basic connection components, and network 
  2375. capabilities to support supplementary services needs further 
  2376. study.
  2377. .RT
  2378. .sp 1P
  2379. .LP
  2380. 2.4
  2381.     \fIAttribute definition\fR 
  2382. .sp 9p
  2383. .RT
  2384. .PP
  2385. A list of definitions of attributes and attribute values is
  2386. contained in Annex\ A to this Recommendation.
  2387. .RT
  2388. .sp 2P
  2389. .LP
  2390. \fB3\fR     \fBApplication to the I\(hySeries Recommendations\fR 
  2391. .sp 1P
  2392. .RT
  2393. .PP
  2394. This technique has been applied in I.200\(hySeries Recommendations for 
  2395. the specification of the telecommunications services supported by and ISDN 
  2396. and in Recommendation\ I.340 for the characterization of ISDN connection 
  2397. types and connection elements. 
  2398. .PP
  2399. The application of the attribute technique for the characterization of 
  2400. multi\(hymedia services is for further study. 
  2401. \v'1P'
  2402. .RT
  2403. .ce 1000
  2404. ANNEX\ A
  2405. .ce 0
  2406. .ce 1000
  2407. (to Recommendation I.140)
  2408. .sp 9p
  2409. .RT
  2410. .ce 0
  2411. .ce 1000
  2412. \fBList of definitions of \fR \fBattributes\fR 
  2413. .sp 9p
  2414. .RT
  2415. .ce 0
  2416. .ce 1000
  2417. \fBand \fR \fBattribute values\fR 
  2418. .ce 0
  2419. .LP
  2420. A.1
  2421.     \fIDefinitions of the attributes\fR 
  2422. .sp 1P
  2423. .RT
  2424. .sp 2P
  2425. .LP
  2426. A.1.1
  2427.     \fITelecomunication service attribute definitions\fR 
  2428. .sp 1P
  2429. .RT
  2430. .sp 1P
  2431. .LP
  2432.     \fBInformation transfer mode\fR 
  2433. .sp 9p
  2434. .RT
  2435. .PP
  2436. This attribute describes the operational mode for transferring
  2437. (transporting and switching) user information through the ISDN.
  2438. .RT
  2439. .sp 2P
  2440. .LP
  2441. \fIPossible values\fR :
  2442.     \(em\ circuit
  2443. .sp 1P
  2444. .RT
  2445. .LP
  2446. \(em\ packet
  2447. .sp 1P
  2448. .LP
  2449.     \fBInformation transfer rate\fR 
  2450. .sp 9p
  2451. .RT
  2452. .PP
  2453. This attribute describes either the bit rate (circuit mode) or the throughput 
  2454. (packet mode). It refers to the transfer of digital information at the 
  2455. access points. 
  2456. .RT
  2457. .sp 2P
  2458. .LP
  2459. \fIPossible values\fR :
  2460.     \(em\ appropriate bit or throughput rate
  2461. .sp 1P
  2462. .RT
  2463. .sp 1P
  2464. .LP
  2465.     \fBInformation transfer capability\fR 
  2466. .sp 9p
  2467. .RT
  2468. .PP
  2469. This attribute describes the capability associated with the
  2470. transfer of different types of information through the ISDN.
  2471. .RT
  2472. .sp 2P
  2473. .LP
  2474. \fIPossible values\fR :
  2475.     \(em\ unrestricted digital information
  2476. .sp 1P
  2477. .RT
  2478. .LP
  2479. \(em\ speech
  2480. .LP
  2481. \(em\ 3.1 kHz audio
  2482. .LP
  2483. \(em\ 7 kHz audio
  2484. .LP
  2485. \(em\ 15 kHz audio
  2486. .LP
  2487. \(em\ video
  2488. .LP
  2489. \(em\ other values
  2490. .bp
  2491. .sp 1P
  2492. .LP
  2493.     \fBStructure\fR 
  2494. .sp 9p
  2495. .RT
  2496. .PP
  2497. This attribute refers to the capability of the ISDN to deliver
  2498. information to the destination access point or reference point in a structure 
  2499. (e.g.\ time interval for circuit mode, service data unit for packet mode), 
  2500. that was presented in a corresponding signal structured at the origin (access 
  2501. point or reference point). 
  2502. .RT
  2503. .sp 2P
  2504. .LP
  2505. \fIPossible values\fR :
  2506.     \(em\ 8 kHz integrity
  2507. .sp 1P
  2508. .RT
  2509. .LP
  2510. \(em\ service data unit integrity
  2511. .LP
  2512. \(em\ time slot sequence integrity
  2513. .LP
  2514. \(em\ restricted differential time delay
  2515. .LP
  2516. \(em\ unstructured
  2517. .sp 1P
  2518. .LP
  2519.     \fBEstablishment of communication\fR 
  2520. .sp 9p
  2521. .RT
  2522. .PP
  2523. This attribute describes the mode of establishment associated to the telecommunication 
  2524. service used to establish and release a given 
  2525. communication.
  2526. .RT
  2527. .sp 2P
  2528. .LP
  2529. \fIPossible values\fR :
  2530.     \(em\ demand
  2531. .sp 1P
  2532. .RT
  2533. .LP
  2534. \(em\ reserved
  2535. .LP
  2536. \(em\ permanent
  2537. .sp 1P
  2538. .LP
  2539.     \fBSymmetry\fR 
  2540. .sp 9p
  2541. .RT
  2542. .PP
  2543. This attribute describes the relationship of information flow
  2544. between two (or more) access points or reference points involved in a
  2545. communication.
  2546. .RT
  2547. .sp 2P
  2548. .LP
  2549. \fIPossible values\fR :
  2550.     \(em\ unidirectional
  2551. .sp 1P
  2552. .RT
  2553. .LP
  2554. \(em\ bidirectional symmetric
  2555. .LP
  2556. \(em\ bidirectional asymmetric
  2557. .sp 1P
  2558. .LP
  2559.     \fBCommunication configuration\fR 
  2560. .sp 9p
  2561. .RT
  2562. .PP
  2563. This attribute describes the spatial arrangement for transferring information 
  2564. between two or more access points. It completes the structure 
  2565. associated with a telecommunication service as it associates the relationship 
  2566. between the access points involved and the flow of information between 
  2567. these 
  2568. access points.
  2569. .RT
  2570. .sp 2P
  2571. .LP
  2572. \fIPossible values\fR :
  2573.     \(em\ point\(hyto\(hypoint
  2574. .sp 1P
  2575. .RT
  2576. .LP
  2577. \(em\ multipoint
  2578. .LP
  2579. \(em\ broadcast
  2580. .sp 1P
  2581. .LP
  2582.     \fBAccess channel and rate\fR 
  2583. .sp 9p
  2584. .RT
  2585. .PP
  2586. This attribute describes the channels and their bit rate used to transfer 
  2587. the user information and/or signalling information at a given access point. 
  2588. .RT
  2589. .sp 2P
  2590. .LP
  2591. \fIPossible values\fR :
  2592.     \(em\ name of the channel (letter) and the corresponding  bit rate
  2593. .sp 1P
  2594. .RT
  2595. .PP
  2596. \fINote\fR \ \(em\ This attribute can be used several times for
  2597. communication characterization.
  2598. .sp 1P
  2599. .LP
  2600.     \fBSignalling access protocol layer\ 1\(hy3, information access
  2601. protocol layer\ 1\(hy3\fR 
  2602. .sp 9p
  2603. .RT
  2604. .PP
  2605. These attributes characterize the protocol on the signalling or
  2606. user information transfer channel at a given access point or reference
  2607. point.
  2608. .RT
  2609. .sp 2P
  2610. .LP
  2611. \fIPossible values\fR :
  2612.     \(em\ appropriate protocol
  2613. .bp
  2614. .sp 1P
  2615. .RT
  2616. .sp 1P
  2617. .LP
  2618.     \fBType of user information\fR 
  2619. .sp 9p
  2620. .RT
  2621. .sp 2P
  2622. .LP
  2623. \fIPossible values\fR :
  2624.     \(em\ speech
  2625. .sp 1P
  2626. .RT
  2627. .LP
  2628. \(em\ sound
  2629. .LP
  2630. \(em\ text
  2631. .LP
  2632. \(em\ facsimile
  2633. .LP
  2634. \(em\ text\(hyfacsimile
  2635. .LP
  2636. \(em\ videotex
  2637. .LP
  2638. \(em\ video
  2639. .LP
  2640. \(em\ text\(hyinteractive
  2641. .sp 1P
  2642. .LP
  2643.     \fBLayer 4\ \(em\ 7 protocol\fR 
  2644. .sp 9p
  2645. .RT
  2646. .PP
  2647. These attributes characterize the protocol on the user information transfer 
  2648. channel at a given access point or reference point. 
  2649. .RT
  2650. .sp 2P
  2651. .LP
  2652. \fIPossible values\fR :
  2653.     \(em\ appropriate protocol
  2654. .sp 1P
  2655. .RT
  2656. .sp 1P
  2657. .LP
  2658.     \fBSupplementary services provided\fR 
  2659. .sp 9p
  2660. .RT
  2661. .PP
  2662. This attribute refers to the supplementary services associated
  2663. with a given telecommunication service.
  2664. .RT
  2665. .sp 1P
  2666. .LP
  2667.     \fBQuality of service\fR 
  2668. .sp 9p
  2669. .RT
  2670. .PP
  2671. This attribute is described by a group of specific sub\(hyattributes, for 
  2672. example: service reliability, service availability. 
  2673. .PP
  2674. The values are under study.
  2675. .RT
  2676. .sp 1P
  2677. .LP
  2678.     \fBInterworking possibilities\fR 
  2679. .sp 9p
  2680. .RT
  2681. .PP
  2682. To be defined.
  2683. .RT
  2684. .sp 1P
  2685. .LP
  2686.     \fBOperational and commercial\fR 
  2687. .sp 9p
  2688. .RT
  2689. .PP
  2690. To be defined.
  2691. .RT
  2692. .sp 2P
  2693. .LP
  2694. A.1.2
  2695.     \fIConnection type attribute definitions\fR 
  2696. .sp 1P
  2697. .RT
  2698. .sp 1P
  2699. .LP
  2700.     \fBInformation transfer mode\fR 
  2701. .sp 9p
  2702. .RT
  2703. .PP
  2704. This attribute describes the operational mode for transferring
  2705. (transporting and switching) user information through the ISDN.
  2706. .RT
  2707. .sp 2P
  2708. .LP
  2709. \fIPossible values\fR :
  2710.     \(em\ circuit
  2711. .sp 1P
  2712. .RT
  2713. .LP
  2714. \(em\ packet
  2715. .sp 1P
  2716. .LP
  2717.     \fBInformation transfer rate\fR 
  2718. .sp 9p
  2719. .RT
  2720. .PP
  2721. This attribute describes either the bit rate (circuit mode) or the throughput 
  2722. (packet mode). It refers to the transfer of digital information 
  2723. between access points or reference points.
  2724. .RT
  2725. .sp 2P
  2726. .LP
  2727. \fIPossible values\fR :
  2728.     \(em\ appropriate bit or throughput rate
  2729. .sp 1P
  2730. .RT
  2731. .sp 1P
  2732. .LP
  2733.     \fBInformation transfer susceptance\fR 
  2734. .sp 9p
  2735. .RT
  2736. .PP
  2737. This attribute describes the capability associated with the
  2738. transfer of different types of information through the ISDN.
  2739. .RT
  2740. .sp 2P
  2741. .LP
  2742. \fIPossible values\fR :
  2743.     \(em\ unrestricted digital information
  2744. .sp 1P
  2745. .RT
  2746. .LP
  2747. \(em\ speech
  2748. .LP
  2749. \(em\ 3.1 kHz audio
  2750. .LP
  2751. \(em\ 7 kHz audio
  2752. .LP
  2753. \(em\ 15 kHz audio
  2754. .LP
  2755. \(em\ video
  2756. .LP
  2757. \(em\ other values
  2758. .bp
  2759. .sp 1P
  2760. .LP
  2761.     \fBEstablishment of connection\fR 
  2762. .sp 9p
  2763. .RT
  2764. .PP
  2765. This attribute describes the mode of establishment used to
  2766. establish and release a given connection in an ISDN.
  2767. .RT
  2768. .sp 2P
  2769. .LP
  2770. \fIPossible values\fR :
  2771.     \(em\ demand
  2772. .sp 1P
  2773. .RT
  2774. .LP
  2775. \(em\ semi\(hypermanent
  2776. .LP
  2777. \(em\ permanent
  2778. .sp 1P
  2779. .LP
  2780.     \fBSymmetry\fR 
  2781. .sp 9p
  2782. .RT
  2783. .PP
  2784. This attribute describes the relationship of information flow
  2785. between two (or more) access points or reference points of a connection.
  2786. .RT
  2787. .sp 2P
  2788. .LP
  2789. \fIPossible values\fR :
  2790.     \(em\ unidirectional
  2791. .sp 1P
  2792. .RT
  2793. .LP
  2794. \(em\ bidirectional symmetric
  2795. .LP
  2796. \(em\ bidirectional asymmetric
  2797. .sp 1P
  2798. .LP
  2799.     \fBConnection configuration\fR 
  2800. .sp 9p
  2801. .RT
  2802. .PP
  2803. This attribute describes the spatial arrangement for transferring information 
  2804. on a given connection. It consists of two sub\(hyattributes, topology and 
  2805. dynamics. 
  2806. .RT
  2807. .sp 1P
  2808. .LP
  2809.     \fBStructure\fR 
  2810. .sp 9p
  2811. .RT
  2812. .PP
  2813. This attribute refers to the capability of the ISDN to deliver
  2814. information to the destination access point or reference point in a structure 
  2815. (e.g.\ time interval for circuit mode, service data unit for packet mode), 
  2816. that was presented in a corresponding signal structured at the origin (access 
  2817. point or reference point). 
  2818. .RT
  2819. .sp 2P
  2820. .LP
  2821. \fIPossible values\fR :
  2822.     \(em\ 8 kHz integrity
  2823. .sp 1P
  2824. .RT
  2825. .LP
  2826. \(em\ service data unit integrity
  2827. .LP
  2828. \(em\ time slot sequence integrity
  2829. .LP
  2830. \(em\ restricted differential time delay
  2831. .LP
  2832. \(em\ unstructured
  2833. .sp 1P
  2834. .LP
  2835.     \fBChannel (rate)\fR 
  2836. .sp 9p
  2837. .RT
  2838. .PP
  2839. This attribute describes the channels and their bit rate used to transfer 
  2840. the user information and/or signalling information at a given access point. 
  2841. .RT
  2842. .sp 2P
  2843. .LP
  2844. \fIPossible values\fR :
  2845.     \(em\ name of the channel (letter) and the corresponding  bit rate
  2846. .sp 1P
  2847. .RT
  2848. .PP
  2849. \fINote\fR \ \(em\ This attribute can be used several times.
  2850. .sp 1P
  2851. .LP
  2852.     \fBConnection control protocol, information transfer
  2853. coding/protocol\fR 
  2854. .sp 9p
  2855. .RT
  2856. .PP
  2857. These attributes characterize the protocol/coding on the
  2858. signalling or user information transfer channel at a given access point or
  2859. reference point.
  2860. .RT
  2861. .sp 2P
  2862. .LP
  2863. \fIPossible values\fR :
  2864.     \(em\ appropriate protocol or coding
  2865. .sp 1P
  2866. .RT
  2867. .sp 1P
  2868. .LP
  2869.     \fBNetwork performance\fR 
  2870. .sp 9p
  2871. .RT
  2872. .PP
  2873. This attribute describes the network performance that relates to an ISDN 
  2874. connection. 
  2875. .bp
  2876. .PP
  2877. This performance attribute consists of sub\(hyattributes, for
  2878. example:
  2879. .RT
  2880. .LP
  2881.     \fIError performance\fR : the values are given in the appropriate
  2882. Recommendations.
  2883. .LP
  2884.     \fISlip performance\fR : the values are given in the appropriate
  2885. Recommendations.
  2886. .PP
  2887. The definition of further sub\(hyattributes is for further study.
  2888. .sp 1P
  2889. .LP
  2890.     \fBNetwork interworking\fR 
  2891. .sp 9p
  2892. .RT
  2893. .PP
  2894. To be defined.
  2895. .RT
  2896. .sp 1P
  2897. .LP
  2898.     \fBOperation and management\fR 
  2899. .sp 9p
  2900. .RT
  2901. .PP
  2902. To be defined.
  2903. .RT
  2904. .sp 2P
  2905. .LP
  2906. A.1.3
  2907.     \fIConnection element attribute defintions\fR 
  2908. .sp 1P
  2909. .RT
  2910. .sp 1P
  2911. .LP
  2912.     \fBInformation transfer mode\fR 
  2913. .sp 9p
  2914. .RT
  2915. .PP
  2916. This attribute describes the operational mode for transferring
  2917. (transporting and switching) user information through the ISDN.
  2918. .RT
  2919. .sp 2P
  2920. .LP
  2921. \fIPossible values\fR :
  2922.     \(em\ circuit
  2923. .sp 1P
  2924. .RT
  2925. .LP
  2926. \(em\ packet
  2927. .sp 1P
  2928. .LP
  2929.     \fBInformation transfer rate\fR 
  2930. .sp 9p
  2931. .RT
  2932. .PP
  2933. This attribute describes either the bit rate (circuit mode) or the throughput 
  2934. (packet mode). It refers to the transfer of digital information 
  2935. between access points or reference points.
  2936. .RT
  2937. .sp 2P
  2938. .LP
  2939. \fIPossible values\fR :
  2940.     \(em\ appropriate bit or throughput rate
  2941. .sp 1P
  2942. .RT
  2943. .sp 1P
  2944. .LP
  2945.     \fBInformation transfer susceptance\fR 
  2946. .sp 9p
  2947. .RT
  2948. .PP
  2949. This attribute identifies equipment which may restrict the types of information 
  2950. which may pass through the ISDN. 
  2951. .RT
  2952. .sp 2P
  2953. .LP
  2954. \fIPossible values\fR :
  2955.     \(em\ speech processing equipment
  2956. .sp 1P
  2957. .RT
  2958. .LP
  2959. \(em\ echo suppression equipment
  2960. .LP
  2961. \(em\ multi\(hysatellite hope
  2962. .LP
  2963. \(em\ null
  2964. .sp 1P
  2965. .LP
  2966.     \fBEstablishment of connection\fR 
  2967. .sp 9p
  2968. .RT
  2969. .PP
  2970. This attribute describes the mode of establishment used to
  2971. establish and release a given connection element in an ISDN.
  2972. .RT
  2973. .sp 2P
  2974. .LP
  2975. \fIPossible values\fR :
  2976.     \(em\ demand
  2977. .sp 1P
  2978. .RT
  2979. .LP
  2980. \(em\ semi\(hypermanent
  2981. .LP
  2982. \(em\ permanent
  2983. .sp 1P
  2984. .LP
  2985.     \fBSymmetry\fR 
  2986. .sp 9p
  2987. .RT
  2988. .PP
  2989. This attribute describes the relationship of information flow
  2990. between two (or more) access points or reference points of a connection
  2991. element.
  2992. .bp
  2993. .RT
  2994. .sp 2P
  2995. .LP
  2996. \fIPossible values\fR :
  2997.     \(em\ undirectional
  2998. .sp 1P
  2999. .RT
  3000. .LP
  3001. \(em\ bidirectional symmetric
  3002. .LP
  3003. \(em\ bidirectional asymmetric
  3004. .sp 1P
  3005. .LP
  3006.     \fBConnection configuration\fR 
  3007. .sp 9p
  3008. .RT
  3009. .PP
  3010. This attribute describes the spatial arrangement for transferring information 
  3011. across a given connection element. It consists of two 
  3012. sub\(hyattributes, topology and uniformity.
  3013. .RT
  3014. .sp 1P
  3015. .LP
  3016.     \fBStructure\fR 
  3017. .sp 9p
  3018. .RT
  3019. .PP
  3020. This attribute refers to the capability of the ISDN to deliver
  3021. information to the destination access point or reference point in a structure 
  3022. (e.g.\ time interval for circuit mode, service data unit for packet mode), 
  3023. that was presented in a corresponding signal structured at the origin (access 
  3024. point or reference point). 
  3025. .RT
  3026. .sp 2P
  3027. .LP
  3028. \fIPossible values\fR :
  3029.     \(em\ 8 kHz integrity
  3030. .sp 1P
  3031. .RT
  3032. .LP
  3033. \(em\ service data unit integrity
  3034. .LP
  3035. \(em\ time slot sequence integrity
  3036. .LP
  3037. \(em\ 8 kHz integrity with restricted differential time delay
  3038. .LP
  3039. \(em\ unstructured
  3040. .sp 1P
  3041. .LP
  3042.     \fBChannel (rate)\fR 
  3043. .sp 9p
  3044. .RT
  3045. .PP
  3046. This attribute describes the channels and their bit rate used to transfer 
  3047. the user information and/or signalling information at a given access point. 
  3048. .RT
  3049. .sp 2P
  3050. .LP
  3051. \fIPossible values\fR :
  3052.     \(em\ name of the channel (letter) and the corresponding  bit rate
  3053. .sp 1P
  3054. .RT
  3055. .PP
  3056. \fINote\fR \ \(em\ This attribute can be used several times.
  3057. .sp 1P
  3058. .LP
  3059.     \fBConnection control protocol, information transfer
  3060. coding/protocol\fR 
  3061. .sp 9p
  3062. .RT
  3063. .PP
  3064. These attributes characterize the protocol/coding on the
  3065. signalling or user information transfer channel at a given access point or
  3066. reference point.
  3067. .RT
  3068. .sp 2P
  3069. .LP
  3070. \fIPossible values\fR :
  3071.     \(em\ appropriate protocol or coding
  3072. .sp 1P
  3073. .RT
  3074. .sp 1P
  3075. .LP
  3076.     \fBNetwork performance\fR 
  3077. .sp 9p
  3078. .RT
  3079. .PP
  3080. This attribute describes the network performance that relate to an ISDN 
  3081. connection element. 
  3082. .PP
  3083. This performance attribute consists of sub\(hyattributes, for
  3084. example:
  3085. .RT
  3086. .LP
  3087.     \fIError performance\fR : The values are given in the appropriate
  3088. Recommendations.
  3089. .LP
  3090.     \fISlip performance\fR : The values are given in the appropriate
  3091. Recommendations.
  3092. .PP
  3093. The definition of further sub\(hyattributes is for further
  3094. study.
  3095. .sp 1P
  3096. .LP
  3097.     \fBNetwork interworking\fR 
  3098. .sp 9p
  3099. .RT
  3100. .PP
  3101. To be defined.
  3102. .RT
  3103. .sp 1P
  3104. .LP
  3105.     \fBOperation and management\fR 
  3106. .sp 9p
  3107. .RT
  3108. .PP
  3109. To be defined.
  3110. .bp
  3111. .RT
  3112. .sp 2P
  3113. .LP
  3114. A.2
  3115.     \fIDefinition of the attribute values\fR 
  3116. .sp 1P
  3117. .RT
  3118. .sp 1P
  3119. .LP
  3120.     \fBunrestricted digital information\fR 
  3121. .sp 9p
  3122. .RT
  3123. .PP
  3124. Transfer of information sequence of bits at its specified bit rate without 
  3125. alteration. 
  3126. .RT
  3127. .LP
  3128.     This\ implies:\ \(em\ bit sequence independence
  3129. .LP
  3130. This\ implies:\ 
  3131. \(em\ digit sequence integrity
  3132. .LP
  3133. This\ implies:\ 
  3134. \(em\ bit integrity.
  3135. .sp 1P
  3136. .LP
  3137.     \fBspeech\fR 
  3138. .sp 9p
  3139. .RT
  3140. .PP
  3141. Digital representation of speech coded according to a specified
  3142. encoding rule (e.g.\ A\(hylaw, \(*m\(hylaw).
  3143. .RT
  3144. .sp 1P
  3145. .LP
  3146.     \fB3.1 kHz audio\fR 
  3147. .sp 9p
  3148. .RT
  3149. .PP
  3150. Digital representation of audio information such as voice\(hyband
  3151. data and speech with a bandwidth of 3.1\ kHz, the encoding rule being specified 
  3152. (e.g.\ A\(hylaw, \(*m\(hylaw). 
  3153. .RT
  3154. .sp 1P
  3155. .LP
  3156.     \fB7 kHz audio\fR 
  3157. .sp 9p
  3158. .RT
  3159. .PP
  3160. Digital representation of audio information with a bandwidth of
  3161. 7\ kHz, the encoding rule being specified.
  3162. .RT
  3163. .sp 1P
  3164. .LP
  3165.     \fB15 kHz audio\fR 
  3166. .sp 9p
  3167. .RT
  3168. .PP
  3169. Digital representation of audio information with a bandwidth of
  3170. 15\ kHz, the encoding rule being specified.
  3171. .RT
  3172. .sp 1P
  3173. .LP
  3174.     \fBvideo\fR 
  3175. .sp 9p
  3176. .RT
  3177. .PP
  3178. Digital representation of video image information, the encoding
  3179. rule being specified.
  3180. .RT
  3181. .sp 1P
  3182. .LP
  3183.     \fB8 kHz integrity\fR 
  3184. .sp 9p
  3185. .RT
  3186. .PP
  3187. This value applies when:
  3188. .RT
  3189. .LP
  3190.     i)
  3191.     at each user\(hynetwork interface, intervals of 125 \(*ms are
  3192. implicitly or explicitly demarcated, and
  3193. .LP
  3194.     ii)
  3195.     all bits submitted within a single demarcated 125 \(*ms
  3196. interval
  3197. are delivered within a corresponding single demarcated 125\ \(*ms interval.
  3198. .sp 1P
  3199. .LP
  3200.     \fBservice data unit integrity\fR 
  3201. .sp 9p
  3202. .RT
  3203. .PP
  3204. This value applies when:
  3205. .RT
  3206. .LP
  3207.     i)
  3208.     at each user\(hynetwork interface, protocols provide a
  3209. mechanism
  3210. for identifying the boundaries of service data units (e.g.\ X.25 complete 
  3211. packet sequence), and 
  3212. .LP
  3213.     ii)
  3214.     all bits submitted within a single service data unit are
  3215. delivered in a corresponding service data unit.
  3216. .sp 1P
  3217. .LP
  3218.     \fBunstructured\fR 
  3219. .sp 9p
  3220. .RT
  3221. .PP
  3222. This value is applicable when the telecommunication service or
  3223. connection neither provides structural boundaries nor preserves structural
  3224. integrity.
  3225. .RT
  3226. .sp 1P
  3227. .LP
  3228.     \fBdemand (communication)\fR 
  3229. .sp 9p
  3230. .RT
  3231. .PP
  3232. The communication can be started as soon as possible after the
  3233. request is made (e.g.\ \fIt\fR\d1\u\ \(em\ \fIt\fR\d0\uis as short as possible). 
  3234. .PP
  3235. Communication and connection release occurs in response to the request 
  3236. of any of the users (calling or called users), \fIt\fR\d3\u\ \(em\ \fIt\fR\d2\uis 
  3237. as short as possible (see Figure\ A\(hy1/I.140). 
  3238. .bp
  3239. .RT
  3240. .LP
  3241. .rs
  3242. .sp 18P
  3243. .ad r
  3244. \fBFigure A\(hy1/I.140, p.\fR 
  3245. .sp 1P
  3246. .RT
  3247. .ad b
  3248. .RT
  3249. .sp 1P
  3250. .LP
  3251.     \fBreserved (communication)\fR 
  3252. .sp 9p
  3253. .RT
  3254. .PP
  3255. The communication can be started at time instant \fIt\fR\d1\uexplicitly 
  3256. specified at the time instant of communication and connection 
  3257. request, \fIt\fR\d0\u. Communication and connection release occurs at time 
  3258. instant \fIt\fR\d3\uexplicitly specified also at \fIt\fR\d0\u. Communication 
  3259. and connection 
  3260. duration is predetermined: the communication and connection is set up for a
  3261. specified period of time. As an option, connection release occurs at time
  3262. instant \fIt\fR\d3\ufollowing a release request made at time instant \fIt\fR\d2\uduring 
  3263. the communication and \fIa priori\fR undetermined (\fIt\fR\d3\u\ \(em\ 
  3264. \fIt\fR\d2\uis as short as possible). This option corresponds to an unspecified 
  3265. duration of the 
  3266. communication and connection, or to a possibility of unanticipated release
  3267. (see Figure\ A.1/I.140).
  3268. .RT
  3269. .sp 1P
  3270. .LP
  3271.     \fBpermanent (communication)\fR 
  3272. .sp 9p
  3273. .RT
  3274. .PP
  3275. The communication can be started after the connection is set up at time 
  3276. instant \fIt\fR\d1\uin response to a subscription request for the service 
  3277. at time instant \fIt\fR\d0\u. the duration may be unspecified. The communication 
  3278. and 
  3279. connection is released at time instant \fIt\fR\d3\ucorresponding to the 
  3280. end of the subscription. 
  3281. .RT
  3282. .sp 1P
  3283. .LP
  3284.     \fBswitched (connection)\fR 
  3285. .sp 9p
  3286. .RT
  3287. .PP
  3288. ISDN circuit switched connections/connection elements are set up at any 
  3289. time on demand via e.g.\ a bit channel in response to signalling 
  3290. information received from subscribers, other exchanges or other networks,
  3291. i.e.\ on a per\(hycall\(hybasis. Message/packet switched connections/connection
  3292. elements provided by an ISDN may be set up on demand via circuit\(hymode 
  3293. channels (e.g.\ B\(hychannels) and special packet switching units or via 
  3294. the D\(hychannel 
  3295. subject to any D\(hychannel priority/flow control restrictions that may be
  3296. applicable.
  3297. .PP
  3298. \fINote\fR \ \(em\ A more general definition of this value is also given in
  3299. Recommendation\ I.112 (No.311).
  3300. .RT
  3301. .sp 1P
  3302. .LP
  3303.     \fBsemi\(hypermanent (connection)\fR 
  3304. .sp 9p
  3305. .RT
  3306. .PP
  3307. Semi\(hypermanent connections/connection elements pass through a
  3308. switching network.
  3309. .PP
  3310. Semi\(hypermanent connections/connection elements between agreed points   may
  3311. be provided for an indefinite period of time after subscription, for a fixed
  3312. period or for agreed periods during a day, week or other interval.
  3313. .bp
  3314. .RT
  3315. .sp 1P
  3316. .LP
  3317.     \fBpermanent (connection)\fR 
  3318. .sp 9p
  3319. .RT
  3320. .PP
  3321. Permanent connections/connection elements are described by the
  3322. following characteristics:
  3323. .PP
  3324. Permanent connections/connection elements are available to the
  3325. connected subscriber at any time during the period of subscription between
  3326. fixed network destination points requested by the subscribers.
  3327. .RT
  3328. .sp 1P
  3329. .LP
  3330.     \fBunidirectional\fR 
  3331. .sp 9p
  3332. .RT
  3333. .PP
  3334. This value applies when the information flow of messages is
  3335. provided only in one direction.
  3336. .RT
  3337. .sp 1P
  3338. .LP
  3339.     \fBbidirectional symmetric\fR 
  3340. .sp 9p
  3341. .RT
  3342. .PP
  3343. This value applies when the information flow characteristics
  3344. provided
  3345. by the service are the same between two (or more) access points or reference
  3346. points in the forward and backward directions.
  3347. .RT
  3348. .sp 1P
  3349. .LP
  3350.     \fBbidirectional asymmetric\fR 
  3351. .sp 9p
  3352. .RT
  3353. .PP
  3354. This value applies when the information flow characteristics
  3355. provided by the service are different in the two directions.
  3356. .RT
  3357. .sp 1P
  3358. .LP
  3359.     \fBpoint\(hyto\(hypoint communication\fR 
  3360. .sp 9p
  3361. .RT
  3362. .PP
  3363. This value applies when there are only two access points.
  3364. .RT
  3365. .sp 1P
  3366. .LP
  3367.     \fBmultipoint communication\fR 
  3368. .sp 9p
  3369. .RT
  3370. .PP
  3371. This value applies when more than two access points (see\ Note) are provided 
  3372. by the service. The exact characteristics of the information flows 
  3373. must be specified separately based on functions provided by the ISDN.
  3374. .PP
  3375. \fINote\fR \ \(em\ The number of access points can be undefined.
  3376. .RT
  3377. .sp 1P
  3378. .LP
  3379.     \fBbroadcast communication\fR 
  3380. .sp 9p
  3381. .RT
  3382. .PP
  3383. This value applies when more than two access points (see\ Note) are provided 
  3384. by the service. The information flows from a unique point (source) to the 
  3385. others (destination) in only one direction. 
  3386. .PP
  3387. \fINote\fR \ \(em\ The number of destination access points is undefined.
  3388. .RT
  3389. .sp 1P
  3390. .LP
  3391.     \fBpoint\(hyto\(hypoint connection\fR 
  3392. .sp 9p
  3393. .RT
  3394. .PP
  3395. This value applies when only two end points are provided by the
  3396. connection.
  3397. .RT
  3398. .sp 1P
  3399. .LP
  3400.     \fBmultipoint connection\fR 
  3401. .sp 9p
  3402. .RT
  3403. .PP
  3404. This value applies when more than two end points are provided by the connection, 
  3405. and thus many different information flows are possible. 
  3406. .RT
  3407. .sp 1P
  3408. .LP
  3409.     \fBbroadcast connection\fR 
  3410. .sp 9p
  3411. .RT
  3412. .PP
  3413. To be defined.
  3414. .RT
  3415. .sp 1P
  3416. .LP
  3417.     \fBsimple connection\fR 
  3418. .sp 9p
  3419. .RT
  3420. .PP
  3421. A connection consisting of only one connection element.
  3422. .RT
  3423. .sp 1P
  3424. .LP
  3425.     \fBtandem connection\fR 
  3426. .sp 9p
  3427. .RT
  3428. .PP
  3429. Two or more connection elements in series form a connection.
  3430. .bp
  3431. .RT
  3432. .sp 1P
  3433. .LP
  3434.     \fBparallel connection\fR 
  3435. .sp 9p
  3436. .RT
  3437. .PP
  3438. Two or more connection elements in parallel form a
  3439. connection.
  3440. .RT
  3441. .sp 1P
  3442. .LP
  3443.     \fBstar\fR 
  3444. .sp 9p
  3445. .RT
  3446. .PP
  3447. To be defined.
  3448. .RT
  3449. .sp 1P
  3450. .LP
  3451.     \fBmesh\fR 
  3452. .sp 9p
  3453. .RT
  3454. .PP
  3455. To be defined.
  3456. .RT
  3457. .sp 1P
  3458. .LP
  3459.     \fBuniform\fR 
  3460. .sp 9p
  3461. .RT
  3462. .PP
  3463. This value applies when all connection elements have the same
  3464. attribute values.
  3465. .RT
  3466. .sp 1P
  3467. .LP
  3468.     \fBnon uniform\fR 
  3469. .sp 9p
  3470. .RT
  3471. .PP
  3472. This value applies in all other cases.
  3473. .RT
  3474. .sp 1P
  3475. .LP
  3476.     \fBconcurrent\fR 
  3477. .sp 9p
  3478. .RT
  3479. .PP
  3480. The configuration of a connection is described as concurrent when all of 
  3481. the connection elements involved are established simultaneously and 
  3482. released simultaneously.
  3483. .RT
  3484. .sp 1P
  3485. .LP
  3486.     \fBsequential\fR 
  3487. .sp 9p
  3488. .RT
  3489. .PP
  3490. A connection has a sequential configuration when its connection
  3491. elements are established and released sequentially i.e.\ only one of several
  3492. connection elements or chains of connection elements exists at any given
  3493. time.
  3494. .RT
  3495. .sp 1P
  3496. .LP
  3497.     \fBadd/remove\fR 
  3498. .sp 9p
  3499. .RT
  3500. .PP
  3501. When connection elements can be established and released while
  3502. other connection elements of the same connections still exist, the
  3503. configuration of this connection is described as add/remove.
  3504. .RT
  3505. .sp 1P
  3506. .LP
  3507.     \fBSymmetry and/or topology change\fR 
  3508. .sp 9p
  3509. .RT
  3510. .PP
  3511. When the symmetry attribute value of the connection element can be changed 
  3512. during a call. 
  3513. .RT
  3514. .sp 1P
  3515. .LP
  3516.     \fBTime slot sequence integrity\fR 
  3517. .sp 9p
  3518. .RT
  3519. .PP
  3520. This value applies when
  3521. .RT
  3522. .LP
  3523.     i)
  3524.      at each user\(hynetwork interface, time slots are implicitly or explicitly 
  3525. demarcated for each access channel of an aggregate of access 
  3526. channels, and
  3527. .LP
  3528.     ii)
  3529.      the information parts delivered from the time slots at the receiving 
  3530. end are in the same order as submitted at the transmitting end. 
  3531. .PP
  3532. \fINote\fR \ \(em\ Preserving the order of bits within an individual time
  3533. slot from the transmitting to the receiving end is not part of this
  3534. definition.
  3535. .sp 1P
  3536. .LP
  3537.     \fB8 kHz integrity with restricted differential time
  3538. delay\ (RDTD)\fR 
  3539. .sp 9p
  3540. .RT
  3541. .PP
  3542. This value applies when the following conditions are
  3543. met:
  3544. .RT
  3545. .LP
  3546.     \(em
  3547.     that at each point in a connection or connection element,
  3548. time slots are explicity or implicitly demarcated for each information 
  3549. channel or an aggregate of information channels; and 
  3550. .LP
  3551.     \(em
  3552.      that the information parts submitted to the time slots at the transmitting 
  3553. end are delivered to the receiving end with a differential time 
  3554. delay of not more than 50\ ms (provisional).
  3555. .bp
  3556. .sp 2P
  3557. .LP
  3558. \fBRecommendation\ I.141\fR 
  3559. .RT
  3560. .sp 2P
  3561. .sp 1P
  3562. .ce 1000
  3563. \fBISDN NETWORK CHARGING CAPABILITIES ATTRIBUTES\fR 
  3564. .EF '%    Fascicle\ III.7\ \(em\ Rec.\ I.141''
  3565. .OF '''Fascicle\ III.7\ \(em\ Rec.\ I.141    %'
  3566. .ce 0
  3567. .sp 1P
  3568. .ce 1000
  3569. \fI(Melbourne, 1988)\fR 
  3570. .sp 9p
  3571. .RT
  3572. .ce 0
  3573. .sp 1P
  3574. .LP
  3575. \fB1\fR     \fBPreamble\fR 
  3576. .sp 1P
  3577. .RT
  3578. .PP
  3579. On the basis of charging principles provided in the D.200\(hySeries, this 
  3580. Recommendation covers the method for identifying the network charging 
  3581. capabilities and provides a candidate list of attributes in Annex\ A.
  3582. .RT
  3583. .sp 2P
  3584. .LP
  3585. \fB2\fR     \fBGeneral\fR 
  3586. .sp 1P
  3587. .RT
  3588. .PP
  3589. ISDNs shall support a range of services as defined in the
  3590. I.200\(hySeries of Recommendations. Charging capabilities and mechanisms 
  3591. need to be associated with each service. 
  3592. .PP
  3593. To ensure that service charging requirements may be supported by
  3594. network charging facilities, it is essential that the service requirements 
  3595. be specified in a format which simplifies the identification of network 
  3596. requirements. The attribute technique is considered an appropriate mechanism 
  3597. by which service requirements may be related to network requirements and 
  3598. has thus been utilized in this Recommendation. (See Figure\ 1/I.141.) 
  3599. .RT
  3600. .LP
  3601. .rs
  3602. .sp 7P
  3603. .ad r
  3604. \fBFigure 1/I.141, p. \fR 
  3605. .sp 1P
  3606. .RT
  3607. .ad b
  3608. .RT
  3609. .sp 2P
  3610. .LP
  3611. \fB3\fR     \fBISDN services characteristics\fR 
  3612. .sp 1P
  3613. .RT
  3614. .PP
  3615. Specifically, the services to which network charging capabilities attributes 
  3616. should be applied are as given in Table\ 1/I.141. 
  3617. .RT
  3618. .LP
  3619. .sp 2
  3620. .ce
  3621. \fBH.T. [T1.141]\fR 
  3622. .ce
  3623. TABLE\ 1/I.141
  3624. .ps 9
  3625. .vs 11
  3626. .nr VS 11
  3627. .nr PS 9
  3628. .TS
  3629. center box;
  3630. cw(90p) | cw(78p) .
  3631. Service    Recommendations
  3632. _
  3633. .T&
  3634. lw(90p) | cw(78p) .
  3635. Bearer services    I.230\(hySeries
  3636. .T&
  3637. lw(90p) | cw(78p) .
  3638. Teleservices    I.240\(hySeries
  3639. .T&
  3640. lw(90p) | cw(78p) .
  3641. Supplementary services    I.250\(hySeries
  3642. _
  3643. .TE
  3644. .nr PS 9
  3645. .RT
  3646. .ad r
  3647. \fBTable 1/I.141 [T1.141], p. \fR 
  3648. .sp 1P
  3649. .RT
  3650. .ad b
  3651. .RT
  3652. .LP
  3653. .bp
  3654. .sp 2P
  3655. .LP
  3656. \fB4\fR     \fBRole and application of the attribute technique\fR 
  3657. .sp 1P
  3658. .RT
  3659. .PP
  3660. For each service defined in the I.200\(hySeries Recommendations, one set 
  3661. of attribute values should be selected for each network charging capability 
  3662. attribute. Assignment of attribute values for a specific service will allow 
  3663. the determination of the network requirements relating to this service.
  3664. .PP
  3665. The definition of charging requirements in terms of network charging capability 
  3666. attributes is intended to provide a link between the service 
  3667. charging characteristics and the respective network charging mechanisms.
  3668. .PP
  3669. Network charging capability attributes are also intended to indicate the 
  3670. range of information to be transferred either within the signalling network 
  3671. or by some other means. 
  3672. .PP
  3673. Annex\ A lists the candidate network charging capability attributes and 
  3674. the possible values so far identified. 
  3675. \v'1P'
  3676. .RT
  3677. .ce 1000
  3678. ANNEX\ A
  3679. .ce 0
  3680. .ce 1000
  3681. (to Recommendation I.141)
  3682. .sp 9p
  3683. .RT
  3684. .ce 0
  3685. .ce 1000
  3686. \fBCandidate network charging capability attributes\fR 
  3687. .sp 1P
  3688. .RT
  3689. .ce 0
  3690. .LP
  3691. .sp 1
  3692. .ce
  3693. \fBH.T. [T2.141]\fR 
  3694. .ce
  3695. TABLE\ A\(hy1/I.141
  3696. .ps 9
  3697. .vs 11
  3698. .nr VS 11
  3699. .nr PS 9
  3700. .TS
  3701. center box;
  3702. cw(78p) | cw(90p) .
  3703. Attribute    Possible values
  3704. _
  3705. .T&
  3706. lw(168p) .
  3707. Charging capabilities
  3708. _
  3709. .T&
  3710. lw(78p) | lw(90p) .
  3711. Usage | ua\d\u)\d     {
  3712. Service requested
  3713. Call attempt | ub\d\u)\d
  3714. Call set\(hyup
  3715. Duration
  3716. Volume
  3717. Basis of provision
  3718.  }
  3719. _
  3720. .T&
  3721. lw(78p) | lw(90p) .
  3722. Modulation    Distance Time of usage
  3723. _
  3724. .T&
  3725. lw(168p) .
  3726. Billing capabilities
  3727. _
  3728. .T&
  3729. lw(78p) | lw(90p) .
  3730. Billing identification     {
  3731. Calling party (sent paid)
  3732. Called party (reverse/collect)
  3733. Transferred (third party)
  3734.  }
  3735. _
  3736. .T&
  3737. lw(78p) | lw(90p) .
  3738. Collection     {
  3739. Subscriber billing
  3740. Credit card
  3741. Coin box
  3742. Debit card
  3743.  }
  3744. _
  3745. .T&
  3746. lw(78p) | lw(90p) .
  3747. Mode     {
  3748. On line
  3749. Off line
  3750.  }
  3751. .TE
  3752. .LP
  3753. \ua\d\u)\d
  3754. The identification and definition of values for supplementary
  3755. services (e.g. registration, activation)
  3756. is for further study.
  3757. .LP
  3758. \ub\d\u)\d
  3759. For further study.
  3760. .nr PS 9
  3761. .RT
  3762. .ad r
  3763. \fBTableau A\(hy1/I.141 [T2.141], p. 13\fR 
  3764. .sp 1P
  3765. .RT
  3766. .ad b
  3767. .RT
  3768. .LP
  3769. .bp
  3770. .LP
  3771. \fBMONTAGE : PAGE 100 = PAGE BLANCHE\fR 
  3772. .sp 1P
  3773. .RT
  3774. .LP
  3775. .bp
  3776.